| Datum | Version | Änderungsbeschreibung |
|---|---|---|
| 2025-08-15 | 1.3 | Kapitel 3.3 "Benutzerorientierte Konzeptentwicklung" mit Unterkapiteln (Personas, Use Cases, Wireframes, Prototyping etc.) und Vergleich zwischen agil/statisch hinzugefügt. |
| 2025-08-13 | 1.2 | Glossar erweitert, detaillierte Beschreibung der Erhebungstechniken (Interview, Workshop, Fragebogen) ergänzt |
| 2025-08-12 | 1.1 | Kapitel 1-3 erstellt |
| 2025-08-12 | 1.0 | Initiale Erstellung |
Willkommen im neuen Schuljahr! In diesem Fach werden wir uns intensiv mit den Kernkompetenzen des Projektmanagements und der Systemkonzeption beschäftigen. Unser Hauptziel ist es, Sie zu befähigen, überschaubare Projekte im Bereich der Software- und Systementwicklung systematisch zu planen, umzusetzen und erfolgreich abzuschließen.
Stellen Sie sich vor, Sie bauen ein komplexes Modell, z. B. ein detailreiches LEGO-Set. Sie würden nicht einfach anfangen, Steine zufällig aufeinanderzusetzen. Stattdessen folgen Sie einer Anleitung, arbeiten sich Schritt für Schritt vor und prüfen regelmäßig, ob alles passt. Genau das tun wir auch im Projektmanagement: Wir folgen einem Plan, um ein digitales Produkt – sei es eine Software, eine App oder ein ganzes IT-System – zu entwickeln.
Die zentralen Themen dieses Jahres umfassen:
Am Ende dieses Jahres sollen Sie in der Lage sein, für ein überschaubares Softwareprojekt die Anforderungen zu analysieren, ein benutzerorientiertes Konzept zu entwickeln, die Umsetzung zu planen, den Fortschritt zu validieren und das Ergebnis sauber zu dokumentieren.
💡 Merksatz: Gutes Projektmanagement ist wie eine detaillierte Landkarte. Sie zeigt uns nicht nur das Ziel, sondern auch den besten Weg dorthin, inklusive möglicher Hindernisse und Alternativrouten.
Um erfolgreich über Projektmanagement und Systemkonzeption sprechen zu können, müssen wir zunächst eine gemeinsame Sprache finden. Stellen Sie sich vor, Sie kochen ein Gericht nach einem neuen Rezept. Begriffe wie "sautieren", "blanchieren" oder "julienne" müssen klar sein, damit das Ergebnis gelingt. In der Softwareentwicklung ist es genauso.
Hier sind die wichtigsten Grundbegriffe, die uns durch das gesamte Jahr begleiten werden:
Projekt: Ein zeitlich begrenztes Vorhaben mit einem definierten Anfang und Ende, das ein einmaliges Produkt, eine Dienstleistung oder ein Ergebnis erzeugt. Ein Projekt hat spezifische Ziele, ein festes Budget und begrenzte Ressourcen.
Anforderung (Requirement): Eine Bedingung oder Fähigkeit, die von einem System oder einer Systemkomponente erfüllt werden muss, um einen Vertrag, einen Standard, eine Spezifikation oder andere formell auferlegte Dokumente zu erfüllen. Man unterscheidet hauptsächlich zwischen:
Stakeholder: Jede Person, Gruppe oder Organisation, die von den Aktivitäten oder dem Ergebnis eines Projekts betroffen ist, es beeinflussen kann oder ein Interesse daran hat.
Requirement-Engineering: Ein systematischer Prozess zur Ermittlung, Dokumentation, Validierung und Verwaltung von Anforderungen für ein System. Es ist die Brücke zwischen den Wünschen der Stakeholder und der technischen Umsetzung.
Projektmanagement: Die Anwendung von Wissen, Fähigkeiten, Werkzeugen und Techniken auf Projektaktivitäten, um die Projektanforderungen zu erfüllen. Es umfasst die Planung, Steuerung, Überwachung und den Abschluss von Projekten.
🔍 Vertiefung: Der Begriff Requirement-Management ist ein Teilbereich des Requirement-Engineerings. Während sich das Engineering auf den gesamten Prozess von der Erhebung bis zur Validierung konzentriert, fokussiert sich das Management speziell auf die Verwaltung, Priorisierung und Nachverfolgung der Anforderungen über den gesamten Projektlebenszyklus.
Diese Begriffe bilden das Fundament für alles Weitere. Es ist entscheidend, sie zu verstehen und korrekt zu verwenden.
Die Methoden des Projektmanagements sind nicht über Nacht entstanden. Sie sind das Ergebnis einer langen Entwicklung, die Hand in Hand mit der industriellen und technologischen Revolution ging.
Stellen Sie sich den Bau der Pyramiden vor. Auch das war ein gigantisches Projekt, das Planung, Koordination von Arbeitskräften und Ressourcenmanagement erforderte, auch wenn die Methoden damals noch nicht formalisiert waren.
Die moderne Geschichte des Projektmanagements beginnt jedoch im 20. Jahrhundert:
Frühes 20. Jahrhundert: Pioniere wie Henry Gantt entwickeln erste Werkzeuge zur Visualisierung von Projektfortschritten. Das nach ihm benannte Gantt-Diagramm ist bis heute ein Standardwerkzeug zur Darstellung von Zeitplänen.
Mitte des 20. Jahrhunderts (Kalter Krieg): Große Militär- und Raumfahrtprojekte (z.B. das Polaris-Raketenprogramm der US Navy) treiben die Entwicklung voran. Methoden wie PERT (Program Evaluation and Review Technique) und die Critical Path Method (CPM) entstehen, um komplexe, voneinander abhängige Aufgaben zu planen und zu steuern.
Die "Softwarekrise" der 1960er und 70er Jahre: Mit der zunehmenden Komplexität von Software stießen Entwickler an ihre Grenzen. Projekte waren oft verspätet, überschritten das Budget oder scheiterten komplett. Als Reaktion darauf entstand das Wasserfallmodell, ein streng sequenzieller Ansatz, bei dem eine Phase nach der anderen abgeschlossen wird (Analyse -> Design -> Implementierung -> Test).
Die agile Revolution (ab den 1990ern): Man erkannte, dass das starre Wasserfallmodell für die dynamische Welt der Softwareentwicklung oft zu unflexibel ist. Als Antwort darauf wurden agile Methoden entwickelt. Das Agile Manifest (2001) formulierte die zentralen Werte:
Bekannte agile Frameworks sind Scrum und Kanban.
💡 Merksatz: Die Entwicklung des Projektmanagements ist eine Reise von starren, plan-getriebenen Modellen (wie dem Wasserfallmodell) hin zu flexiblen, iterativen Ansätzen (wie Scrum), die besser auf die Unvorhersehbarkeit moderner Projekte reagieren können.
Diese historische Perspektive hilft uns zu verstehen, warum es heute so viele verschiedene Methoden gibt und welche für welches Problem am besten geeignet ist.
Nachdem wir die historische Entwicklung betrachtet haben, ist es wichtig, die beiden großen Philosophien im modernen Projektmanagement direkt zu vergleichen: traditionelle (plan-getriebene) Ansätze wie das Wasserfallmodell und agile (veränderungs-getriebenen) Ansätze wie Scrum.
Stellen Sie es sich wie den Bau eines Hauses vor:
Hier ist ein direkter Vergleich der wichtigsten Merkmale:
| Merkmal | Traditionelles Modell (z.B. Wasserfall) | Agiles Modell (z.B. Scrum) |
|---|---|---|
| Planung | Detaillierte Vorausplanung des gesamten Projekts | Grobe Vision am Anfang, detaillierte Planung in kurzen Zyklen (Sprints) |
| Anforderungen | Werden zu Beginn vollständig definiert und "eingefroren" | Sind dynamisch und können sich während des Projekts ändern |
| Prozess | Sequenziell: Eine Phase muss abgeschlossen sein, bevor die nächste beginnt | Iterativ & Inkrementell: Das Produkt wird in kleinen, funktionsfähigen Teilen entwickelt |
| Dokumentation | Umfassend und ein zentraler Bestandteil des Prozesses | Fokussiert auf das Nötigste; funktionierende Software ist wichtiger |
| Kunden-Einbindung | Hauptsächlich am Anfang (Anforderungen) und am Ende (Abnahme) | Kontinuierliche Zusammenarbeit und regelmäßiges Feedback |
| Umgang mit Änderungen | Änderungen sind schwierig und teuer; werden möglichst vermieden | Änderungen sind willkommen und ein integraler Bestandteil des Prozesses |
| Ideal für... | Projekte mit sehr stabilen, vorab definierten Anforderungen (z.B. die Firmware für einen Herzschrittmacher) | Projekte, bei denen sich die Anforderungen wahrscheinlich ändern werden (z.B. die Entwicklung einer neuen Social-Media-App) |
⚠️ Achtung: Kein Ansatz ist per se "besser" als der andere. Die Wahl der richtigen Methode hängt immer vom Projekt, dem Team, dem Kunden und dem Umfeld ab. In der Praxis existieren oft auch hybride Modelle, die Elemente aus beiden Welten kombinieren (z.B. water-scrum-fall-model])
Dieses Verständnis der grundlegenden Unterschiede ist entscheidend, um im Laufe des Jahres die verschiedenen Techniken und Werkzeuge korrekt einordnen zu können.
Wie wir in Kapitel 2.3 gesehen haben, gibt es keinen "besten" Ansatz für alle Projekte. Die Entscheidung zwischen einem traditionellen, plan-getriebenen Vorgehen (wie dem Wasserfallmodell) und einem agilen, veränderungs-getriebenen Ansatz (wie Scrum) ist eine der wichtigsten Weichenstellungen zu Beginn eines Projekts. Die falsche Wahl kann zu Frustration, Verzögerungen und im schlimmsten Fall zum Scheitern des Projekts führen.
Stellen Sie sich vor, Sie planen eine Reise. Wenn das Ziel ein bekanntes, gut erreichbares All-Inclusive-Resort ist, können Sie die gesamte Reise von Flug über Hotel bis zu den Ausflügen im Voraus exakt durchplanen (traditioneller Ansatz). Wenn Sie jedoch mit einem Rucksack durch ein unbekanntes Land reisen, planen Sie vielleicht nur die erste Unterkunft und entscheiden dann spontan und flexibel, wohin es als Nächstes geht (agiler Ansatz).
Um die richtige Entscheidung für Ihr Projekt zu treffen, sollten Sie die folgenden Schlüsselfaktoren bewerten:
| Faktor | Traditionell (Wasserfall) ist besser geeignet, wenn... | Agil (Scrum) ist besser geeignet, wenn... |
|---|---|---|
| Anforderungen | ...die Anforderungen von Anfang an klar, detailliert und stabil sind. Änderungen sind unwahrscheinlich oder müssen streng kontrolliert werden. | ...die Anforderungen zu Beginn unklar sind, sich wahrscheinlich ändern werden oder erst im Laufe des Projekts entdeckt werden. |
| Kunde & Stakeholder | ...der Kunde eine detaillierte Planung und einen festen Preis zu Beginn wünscht und nur zu definierten Meilensteinen verfügbar ist. | ...der Kunde bereit und in der Lage ist, kontinuierlich und eng mit dem Entwicklungsteam zusammenzuarbeiten und regelmäßig Feedback zu geben. |
| Projektumfeld | ...das Umfeld stabil und vorhersehbar ist. Es gibt wenige externe Abhängigkeiten oder technologische Unsicherheiten. | ...das Projekt in einem dynamischen, sich schnell ändernden Markt stattfindet oder neue, unerprobte Technologien verwendet werden. |
| Team & Kultur | ...das Team an klare Hierarchien und detaillierte Arbeitsanweisungen gewöhnt ist. Die Rollen sind klar getrennt. | ...das Team selbstorganisiert, interdisziplinär und entscheidungsfreudig ist. Eine offene Kommunikations- und Fehlerkultur wird gelebt. |
| Risikomanagement | ...das Hauptrisiko in der Nichteinhaltung des initialen Plans (Zeit, Budget, Umfang) liegt. Das Ziel ist Planerfüllung. | ...das Hauptrisiko darin besteht, am Ende ein Produkt zu liefern, das der Markt nicht will. Das Ziel ist die Maximierung des Kundenwerts. |
💡 Merksatz: Die Faustregel lautet: Je unklarer das Ziel und je dynamischer das Umfeld, desto eher eignet sich ein agiler Ansatz. Je klarer das Ziel und je stabiler das Umfeld, desto eher kann ein traditioneller Ansatz erfolgreich sein.
In der realen Welt sind die Grenzen oft fließend. Viele Organisationen nutzen daher hybride Modelle, die versuchen, das Beste aus beiden Welten zu vereinen – zum Beispiel eine grobe, traditionelle Rahmenplanung für das Gesamtprojekt, aber eine agile Umsetzung der einzelnen Arbeitspakete.
Um die Theorie greifbarer zu machen, betrachten wir drei typische Softwareentwicklungsprojekte und analysieren, welcher Ansatz am besten passt.
Projektbeschreibung: Ein Unternehmen entwickelt eine neue Generation von Blutzuckermessgeräten. Die Software (Firmware) auf dem Gerät muss absolut zuverlässig und fehlerfrei funktionieren. Die Anforderungen sind durch medizinische Standards und gesetzliche Vorschriften (z.B. MPG - Medizinproduktegesetz) streng vorgegeben.
Analyse der Faktoren:
Empfohlene Methode: Traditionelles Vorgehen (Wasserfallmodell)
Projektbeschreibung: Ein Startup möchte eine innovative App entwickeln, die Funktionen von TikTok und Instagram kombiniert, um eine Nische im Markt zu besetzen. Zu Beginn gibt es nur eine grobe Idee, aber kein klares Bild von den finalen Features. Der Erfolg hängt davon ab, wie schnell die App auf Trends und Nutzerfeedback reagieren kann.
Analyse der Faktoren:
Empfohlene Methode: Agiles Vorgehen (Scrum)
Projektbeschreibung: Ein etabliertes Versicherungsunternehmen möchte seinen papierbasierten Prozess zur Schadensmeldung durch eine moderne Web-Anwendung ersetzen. Der grundlegende Prozess (Schaden melden, Gutachter beauftragen, Auszahlung freigeben) ist klar definiert und muss sich in die bestehende IT-Landschaft (z.B. Kundendatenbank, Buchhaltungssystem) integrieren. Gleichzeitig soll die neue Anwendung aber benutzerfreundlicher und moderner sein als die alten Systeme.
Analyse der Faktoren:
Empfohlene Methode: Hybrides Vorgehen (z.B. Water-Scrum-Fall)
Das Requirementmanagement ist das Fundament jedes erfolgreichen Projekts. Wenn wir nicht genau wissen, was wir bauen sollen, ist die Wahrscheinlichkeit hoch, dass wir am Ende etwas liefern, das niemand braucht oder will.
Stellen Sie sich vor, Sie bestellen in einem Restaurant ein "gutes Essen". Der Kellner könnte Ihnen ein perfekt zubereitetes Steak bringen, obwohl Sie eigentlich Lust auf eine vegetarische Lasagne hatten. Das Steak mag objektiv gut sein, aber es erfüllt Ihre (unausgesprochene) Anforderung nicht. Requirementmanagement sorgt dafür, dass wir die Bestellung des Kunden von Anfang an richtig aufnehmen.
Die Hauptziele des Requirementmanagements sind:
💡 Merksatz: Requirementmanagement ist der Prozess, sicherzustellen, dass das richtige System mit den richtigen Funktionen für die richtigen Leute gebaut wird.
Wie bereits in Kapitel 2.1 erwähnt, ist das Requirementmanagement ein Teilbereich des Requirement-Engineerings. Das Engineering umfasst den gesamten Prozess von der ersten Idee bis zur finalen Abnahme der Anforderung, während sich das Management auf die kontinuierliche Verwaltung, Priorisierung und Nachverfolgung dieser Anforderungen konzentriert.
Jetzt wird es praktisch. Wie kommen wir an die Anforderungen? Es reicht selten aus, den Kunden einfach zu fragen: "Was willst du?" Oft wissen die Stakeholder selbst nicht im Detail, was möglich ist oder was sie genau benötigen. Unsere Aufgabe ist es, wie ein Detektiv die wahren Bedürfnisse zu ermitteln.
Stellen Sie sich vor, Sie sollen ein "besseres Klassenzimmer" gestalten. Sie würden nicht nur den Lehrer fragen. Sie würden Schüler beobachten, den Hausmeister interviewen, vielleicht sogar eine Umfrage machen. Genau das tun wir hier auch, nur mit anderen Techniken.
Man unterscheidet grob zwischen Erhebungstechniken (Wie komme ich an die Information?) und Beschreibungstechniken (Wie halte ich die Information fest?).
Interview: Das direkte Gespräch mit einem Stakeholder. Es ist ideal, um tiefes Wissen von Einzelpersonen zu erhalten.
Workshop: Ein moderiertes Treffen mit einer Gruppe von Stakeholdern. Ziel ist es, gemeinsam Anforderungen zu erarbeiten und Konflikte zu lösen.
Fragebogen/Umfrage: Eine standardisierte Sammlung von Fragen, die an eine große Anzahl von Personen verteilt wird.
Beobachtung (Feldbeobachtung): Der Analyst beobachtet den Benutzer direkt in seiner Arbeitsumgebung, um zu verstehen, wie er aktuell arbeitet.
Das Interview ist eine der fundamentalsten Techniken zur Anforderungserhebung. Es handelt sich um ein direktes, interaktives Gespräch zwischen einem Anforderungsanalysten und einem Stakeholder mit dem Ziel, Wissen, Meinungen und Wünsche zu ermitteln.
Ziel und Zweck: Das Hauptziel besteht darin, tiefgehendes und spezifisches Wissen zu erlangen, das in Dokumenten oft nicht zu finden ist. Interviews eignen sich besonders gut, um:
Arten von Interviews: Je nach Grad der Vorstrukturierung unterscheidet man drei Hauptformen:
Ablauf (Phasen eines Interviews):
Vorbereitung:
Durchführung:
Nachbereitung:
💡 Tipp: Aktives Zuhören ist die wichtigste Fähigkeit bei einem Interview. Das bedeutet nicht nur zu hören, was gesagt wird, sondern auch zu versuchen, die Perspektive des anderen wirklich zu verstehen und durch gezielte Rückfragen (z.B. "Habe ich richtig verstanden, dass...") sicherzustellen, dass keine Missverständnisse entstehen.
Stellen Sie sich vor, statt einzeln mit jedem Handwerker (Elektriker, Installateur, Maler) zu sprechen, um ein Zimmer zu renovieren, holen Sie alle an einen Tisch, um den Plan gemeinsam zu entwerfen. Genau das ist ein Workshop: ein kollaboratives Meeting, um schnell zu einem gemeinsamen, abgestimmten Ergebnis zu kommen.
Ein Workshop ist ein strukturiertes, moderiertes Arbeitstreffen, bei dem eine Gruppe von ausgewählten Stakeholdern zusammenkommt, um in kurzer Zeit ein gemeinsames, vordefiniertes Ziel zu erreichen. Im Requirement-Engineering ist dieses Ziel oft die gemeinsame Erarbeitung, Diskussion, Priorisierung und Validierung von Anforderungen.
Ziel und Zweck:
Wichtige Rollen:
Ablauf (Phasen eines Workshops):
Vorbereitung:
Durchführung:
Nachbereitung:
⚠️ Achtung: Ein Workshop ist nur so gut wie seine Vorbereitung und Moderation. Ohne klares Ziel und eine starke, neutrale Führung kann ein Workshop schnell zu einer unproduktiven "Quasselrunde" werden oder von dominanten Einzelpersonen gekapert werden.
Stellen Sie sich vor, Sie möchten die Meinung aller Schülerinnen und Schüler Ihrer Schule zu einem neuen Mensa-Angebot einholen. Einzelne Interviews oder Workshops wären viel zu aufwendig. Hier kommt der Fragebogen ins Spiel: ein Werkzeug, um schnell und standardisiert Daten von einer großen Gruppe zu sammeln.
Ein Fragebogen (oder eine Umfrage) ist eine systematische Zusammenstellung von Fragen, die einer definierten Personengruppe vorgelegt wird, um quantitative oder qualitative Daten zu einem bestimmten Thema zu erheben.
Ziel und Zweck:
Arten von Fragen: Die Qualität eines Fragebogens hängt entscheidend von der Formulierung und Art der Fragen ab:
Geschlossene Fragen: Geben Antwortmöglichkeiten vor.
Offene Fragen: Erlauben eine freie Antwort in eigenen Worten.
Skalenfragen (Rating-Skalen): Dienen der Bewertung von Merkmalen auf einer Skala (z.B. von 1 bis 5).
Ablauf (Phasen einer Umfrage):
Vorbereitung:
Durchführung:
Nachbereitung:
💡 Merksatz: Ein guter Fragebogen ist wie ein präzises Messinstrument. Er liefert nur dann verlässliche Daten, wenn die Fragen sorgfältig "geeicht" (formuliert und getestet) wurden. Eine Mischung aus geschlossenen Fragen für die Statistik und einigen offenen Fragen für unerwartete Einblicke ist oft am effektivsten.
Einmal erhoben, müssen Anforderungen klar und unmissverständlich dokumentiert werden.
User Stories (Agile Welt): Eine kurze, einfache Beschreibung einer Funktion aus der Sicht des Nutzers. Das Format ist meist:
Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen> zu erreichen.
Use Cases (Traditionelle Welt): Beschreiben die Interaktion zwischen einem Akteur (Benutzer oder ein anderes System) und dem System, um ein bestimmtes Ziel zu erreichen. Sie sind oft detaillierter als User Stories und werden häufig mit Diagrammen (UML Use-Case-Diagramm) visualisiert.
Lastenheft und Pflichtenheft:
🔍 Vertiefung: Die Wahl der Technik hängt vom Projekt ab. In agilen Projekten wie mit Scrum sind User Stories und häufige Workshops sehr beliebt. In großen, traditionellen Projekten sind Interviews und die Erstellung eines detaillierten Pflichtenhefts oft Standard.
Stellen Sie sich vor, Sie beschreiben einem Freund eine Filmidee. Sie würden nicht mit technischen Details zur Kameraführung beginnen, sondern mit der Geschichte aus der Sicht der Hauptfigur: "Ein junger Held möchte den Schatz finden, um sein Dorf zu retten." Genau das ist die Essenz einer User Story: eine Anforderung aus der Perspektive desjenigen zu erzählen, der sie hat.
Eine User Story ist eine kurze, einfache Beschreibung einer Funktionalität, formuliert in der Alltagssprache des Anwenders oder Kunden. Sie ist das zentrale Artefakt zur Anforderungsbeschreibung in agilen Frameworks wie Scrum.
Ziel und Zweck:
Struktur und Bestandteile (Die 3 "C"s): Eine gute User Story folgt dem 3-C-Modell von Ron Jeffries:
Card (Karte): Die Anforderung wird auf eine Karte (oder ein virtuelles Ticket, z.B. in Jira) geschrieben. Sie folgt meist dem Format:
Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen> zu erreichen.
Conversation (Konversation): Die Details hinter der Story werden in Gesprächen zwischen dem Entwicklungsteam und dem Product Owner geklärt. Hier werden Fragen gestellt, Annahmen hinterfragt und Missverständnisse ausgeräumt.
Confirmation (Bestätigung): Die Akzeptanzkriterien definieren, wann eine User Story als "fertig" gilt. Sie sind die Checkliste, anhand derer die Story getestet wird.
💡 Merksatz (INVEST): Gute User Stories erfüllen die INVEST-Kriterien. Sie sind:
- Independent (Unabhängig von anderen Stories)
- Negotiable (Verhandelbar, nicht in Stein gemeißelt)
- Valuable (Wertvoll für den Nutzer oder Kunden)
- Estimable (Schätzbar im Aufwand)
- Small (Klein genug, um in einer Iteration umsetzbar zu sein)
- Testable (Testbar, d.h. es gibt klare Akzeptanzkriterien)
Wenn eine User Story die kurze, prägnante Erzählung einer Filmidee ist, dann ist ein Use Case das detaillierte Drehbuch für eine bestimmte Szene. Er beschreibt Schritt für Schritt, was passiert, wer was sagt und was bei unerwarteten Wendungen geschieht.
Ein Use Case (deutsch: Anwendungsfall) beschreibt die Interaktion zwischen einem Akteur und dem System, um ein bestimmtes, wertschöpfendes Ziel zu erreichen. Er fokussiert auf das "Was" (die funktionale Anforderung) aus einer externen Perspektive und modelliert einen vollständigen Ablauf.
Ziel und Zweck:
Bestandteile eines Use Cases (Textuelle Beschreibung): Ein Use Case wird oft durch ein UML-Diagramm visualisiert, aber seine wahre Stärke liegt in der textuellen Ausformulierung. Typische Elemente sind:
Visuelle Darstellung (UML Use-Case-Diagramm): Das Diagramm bietet einen schnellen Überblick über die Hauptfunktionen eines Systems und ihre Beziehungen zu den Akteuren.
🔍 Vertiefung: User Story vs. Use Case
- Eine User Story ist klein, auf den Nutzen fokussiert und eine "Einladung zur Konversation". Sie beschreibt ein "Stück" Funktionalität.
- Ein Use Case ist detailliert, auf den Prozess fokussiert und eine "Spezifikation". Er beschreibt oft einen kompletten Geschäftsvorfall, der mehrere User Stories umfassen kann.
Beispiel: Der Use Case "Online-Bestellung durchführen" könnte aus den User Stories "Als Kunde möchte ich Artikel in den Warenkorb legen...", "Als Kunde möchte ich meine Lieferadresse auswählen..." und "Als Kunde möchte ich mit Kreditkarte bezahlen..." bestehen.
Stellen Sie sich den Bau eines Hauses vor. Das Lastenheft ist die detaillierte Wunschliste des Bauherrn an den Architekten: "Ich wünsche mir ein Haus mit drei Schlafzimmern, einer großen Wohnküche, bodentiefen Fenstern und einer Solaranlage auf dem Dach." Es beschreibt, was gewünscht wird. Das Pflichtenheft ist die Antwort des Architekten: "Basierend auf Ihren Wünschen entwerfe ich ein zweistöckiges Haus in Holzständerbauweise mit einer Wärmepumpe und den im Plan spezifizierten Fenstern, um Ihre Anforderungen zu erfüllen." Es beschreibt, wie die Wünsche umgesetzt werden.
Das Lastenheft (Anforderungsspezifikation des Auftraggebers)
Das Lastenheft, oft auch als Anforderungskatalog oder User-Requirements-Spezifikation (URS) bezeichnet, ist das Dokument, in dem der Auftraggeber (Kunde) die Gesamtheit seiner Anforderungen an das zu liefernde System aus seiner fachlichen Perspektive beschreibt.
Das Pflichtenheft (Technische Lösungsspezifikation des Auftragnehmers)
Das Pflichtenheft, auch als technische Spezifikation oder auch als System-Requirements-Specification (SRS) bekannt, ist die Antwort des Auftragnehmers (Entwicklungsteam) auf das Lastenheft. Es beschreibt detailliert, wie die im Lastenheft genannten Anforderungen technisch und konzeptionell umgesetzt werden sollen.
⚠️ Achtung: In der Praxis ist die Trennung nicht immer so scharf. Oft werden beide Dokumente in enger Zusammenarbeit erstellt. Im agilen Vorgehen werden Lasten- und Pflichtenhefte oft durch ein kontinuierlich gepflegtes Product Backlog und detaillierte User Stories ersetzt. In formalen Vertragssituationen sind sie jedoch nach wie vor ein unverzichtbarer Standard.
Selten können alle Anforderungen auf einmal umgesetzt werden. Zeit, Budget und Ressourcen sind begrenzt. Daher ist es entscheidend, herauszufinden, welche Anforderungen am wichtigsten sind. Die Priorisierung hilft dem Team, sich auf das Wesentliche zu konzentrieren und den größten Nutzen für den Kunden so früh wie möglich zu liefern.
Stellen Sie sich vor, Sie packen einen Koffer für eine Reise. Sie können nicht Ihren gesamten Kleiderschrank mitnehmen. Also müssen Sie entscheiden: Die Regenjacke für die Wanderung ist ein Muss, die schicken Abendschuhe sind vielleicht nur "nice to have". Genau das tun wir bei der Anforderungspriorisierung.
Das Kano-Modell, entwickelt von Professor Noriaki Kano, ist ein mächtiges Werkzeug, um die emotionale Wirkung von Produktmerkmalen auf die Kundenzufriedenheit zu verstehen. Es geht über die einfache Frage "Ist das wichtig?" hinaus und hilft zu erkennen, wie ein Merkmal die Zufriedenheit beeinflusst.
Das Modell unterscheidet fünf Arten von Merkmalen:
Basis-Merkmale (Must-haves):
Leistungs-Merkmale (Performance):
Begeisterungs-Merkmale (Delighters/Exciters):
Unerhebliche Merkmale (Indifferent):
Rückweisungs-Merkmale (Reverse):
💡 Merksatz: Das Kano-Modell hilft uns zu verstehen, dass nicht alle Anforderungen gleich sind. Wir müssen zuerst die Basis-Merkmale erfüllen, um nicht zu scheitern, dann in Leistungs-Merkmale investieren, um wettbewerbsfähig zu sein, und gezielt Begeisterungs-Merkmale einstreuen, um Kunden zu Fans zu machen.
Anwendung in der Praxis: Um herauszufinden, zu welcher Kategorie ein Merkmal gehört, werden gezielte Kundenbefragungen durchgeführt. Für jedes Merkmal werden zwei Fragen gestellt (funktionale und dysfunktionale Form):
Die Antwortmöglichkeiten sind standardisiert (z.B. "Das würde mich sehr freuen", "Das setze ich voraus", "Das ist mir egal", "Das würde mich nicht stören", "Das würde mich sehr stören"). Aus der Kombination der beiden Antworten lässt sich jedes Merkmal einer der Kano-Kategorien zuordnen.
Dynamik des Modells: Die Einordnung von Merkmalen ist nicht statisch, sondern ändert sich im Laufe der Zeit durch den technologischen Fortschritt und die Gewöhnung der Kunden:
🔍 Vertiefung: Diese Dynamik bedeutet, dass eine Kano-Analyse regelmäßig wiederholt werden muss, um sicherzustellen, dass das Produkt weiterhin den aktuellen Kundenerwartungen entspricht und nicht von der Konkurrenz überholt wird.
Die MoSCoW-Methode ist eine einfache und sehr verbreitete Technik zur Priorisierung von Anforderungen, insbesondere in agilen Projekten und bei zeitkritischen Vorhaben. Der Name ist ein Akronym aus den Anfangsbuchstaben der vier Prioritätskategorien:
M - Must have (Muss-Anforderung):
S - Should have (Soll-Anforderung):
C - Could have (Kann-Anforderung):
W - Won't have (Wird es nicht geben):
⚠️ Die größte Gefahr bei der MoSCoW-Methode ist, dass zu viele Anforderungen als "Must-have" klassifiziert werden. Eine gute Regel ist, dass die "Must-haves" nicht mehr als 60% des Gesamtaufwands ausmachen sollten, um Puffer für die "Should-" und "Could-haves" zu lassen.
Nachdem wir wissen, was zu tun ist (Anforderungen), müssen wir definieren, wie der Benutzer mit dem System interagiert, um seine Ziele zu erreichen. Hier kommt die Gestaltung der Benutzererfahrung (engl. User Experience Design, UX Design) ins Spiel. Sie ist die Kunst und Wissenschaft, ein Produkt zu schaffen, das nicht nur technisch funktioniert, sondern auch nützlich, benutzbar und erfreulich in der Anwendung ist.
Stellen Sie sich vor, Sie entwerfen eine neue Küchenmaschine. Sie würden nicht nur den Motor und die Klingen konstruieren, sondern sich genau überlegen, wie der Koch die Maschine hält, wie er die Geschwindigkeiten regelt und wie einfach sie zu reinigen ist. Sie gestalten die gesamte Erfahrung der Nutzung. Im UX Design übersetzen wir die abstrakten Anforderungen in greifbare Konzepte, die den Nutzer in den Mittelpunkt stellen.
Dieser kreative Prozess ruht auf drei wesentlichen Säulen:
Sobald wir wissen, für wen wir entwickeln (z.B. mithilfe von Personas) und was die Ziele sind (z.B. mithilfe von User Stories), beginnen wir, die Benutzeroberfläche (User Interface, UI) zu skizzieren. Dies geschieht in zwei wesentlichen, aufeinander aufbauenden Schritten:
Wireframes (Drahtgittermodelle)
Ein Wireframe ist ein schematischer, grober Entwurf einer Benutzeroberfläche, der sich ausschließlich auf die Struktur, das Layout und die Anordnung der Elemente konzentriert. Er ist wie der Bauplan eines Hauses: Er zeigt, wo Wände, Türen und Fenster sind, aber nicht, welche Tapete oder Bodenfarbe verwendet wird.
Mockups (Design-Entwürfe)
Ein Mockup ist ein detaillierter, statischer Entwurf, der bereits das visuelle Design (Farben, Schriftarten, Icons, Abstände) zeigt. Er ist wie eine fotorealistische 3D-Visualisierung des fertigen Hauses. Er sieht aus wie das Endprodukt, ist aber noch nicht interaktiv.
| Eigenschaft | Wireframe (Bauplan) | Mockup (Visualisierung) |
|---|---|---|
| Detailgrad | Niedrig (Low-Fidelity) | Hoch (High-Fidelity) |
| Fokus | Struktur, Layout, Funktion | Visuelles Design, Ästhetik |
| Farben | Meist Graustufen | Finale Farbpalette |
| Ziel | Schnelle Iteration, Konzeptvalidierung | Finale Design-Abnahme, Vorlage für Entwicklung |
💡 Merksatz: Erst die Struktur (Wireframe), dann die Schönheit (Mockup). Dieser gestufte Prozess verhindert, dass man sich zu früh in Designdetails verliert, und stellt sicher, dass die Grundlage der Benutzerführung solide ist.
Ein schönes Design allein reicht nicht. Das System muss vor allem benutzbar sein. Das ist das Kernziel der Usability (Gebrauchstauglichkeit). Usability beschreibt das Ausmaß, in dem ein Produkt von bestimmten Benutzern verwendet werden kann, um bestimmte Ziele effektiv, effizient und zufriedenstellend in einem bestimmten Nutzungskontext zu erreichen.
Wichtige Prinzipien der Usability sind:
Ein wichtiger Aspekt der Usability ist die Barrierefreiheit (Accessibility). Sie stellt sicher, dass auch Menschen mit dauerhaften oder temporären Einschränkungen (z.B. Sehschwäche, Farbenblindheit, motorische Einschränkungen) das System ohne Hürden nutzen können. Dazu gehören z.B. ausreichende Farbkontraste, alternative Texte für Bilder (für Screenreader) und die vollständige Bedienbarkeit per Tastatur.
💡 Merksatz: Gutes Design ist unsichtbar. Wenn ein Nutzer nicht über die Bedienung nachdenken muss, sondern seine Ziele einfach erreicht, wurde Usability richtig umgesetzt.
Wie finden wir heraus, ob unser Konzept aus Wireframes und Mockups wirklich gut ist? Indem wir es von echten Nutzern testen lassen, bevor auch nur eine Zeile Code geschrieben wurde. Dafür bauen wir Prototypen.
Ein Prototyp ist ein interaktives, klickbares Modell des Systems. Er simuliert die Funktionalität und die Benutzerführung und macht Konzepte so direkt erlebbar. Der Hauptzweck ist es, Annahmen schnell und kostengünstig zu überprüfen und durch echtes Nutzerfeedback zu lernen. Es ist weitaus günstiger, einen Fehler in einem Prototypen zu finden, als in der fertig programmierten Software.
Die Werkzeuge und Methoden für das Prototyping haben sich rasant entwickelt. Sehen wir uns die modernsten Ansätze an.
Moderne Design-Tools wie Figma, Sketch oder Adobe XD sind das Herzstück des heutigen UX/UI-Designs. Figma hat sich dabei als führende, cloud-basierte Plattform etabliert.
Mit Figma können Teams:
Der Prozess sieht oft so aus:
Eine neue Generation von Werkzeugen nutzt Künstliche Intelligenz, um den Prozess von der Idee zum Prototyp radikal zu beschleunigen.
Beispiel: Stitch von Google (stitch.withgoogle.com)
Stitch ist ein experimentelles Tool von Google Labs, das die multimodalen Fähigkeiten von KI-Modellen wie Gemini nutzt. Es ermöglicht, UI-Designs und sogar Frontend-Code direkt aus einfachen Beschreibungen zu generieren.
Diese Tools ersetzen nicht den Designer, aber sie beschleunigen die ersten Schritte enorm. Man kann in kürzester Zeit viele verschiedene Design-Varianten erzeugen und testen, bevor man sich für eine Richtung entscheidet und diese in einem Tool wie Figma verfeinert.
Neben spezialisierten Tools können auch allgemeine KI-Chatbots wie ChatGPT, Claude oder Gemini als wertvolle Assistenten im Prototyping-Prozess dienen. Ihr Einsatzbereich ist die schnelle Erstellung von Code-Prototypen.
Anstatt ein visuelles Mockup zu erstellen, generiert man direkt funktionalen, aber einfachen Code (z.B. HTML, CSS, JavaScript, oft mit Frameworks wie React oder Vue).
Ein typischer Workflow:
vue.js) als One Pager, für eine Produkt-Detailseite. Sie soll oben ein großes Bild haben, rechts daneben den Produkttitel, eine kurze Beschreibung und einen 'In den Warenkorb'-Button. Darunter sollen drei kleine Bilder für weitere Ansichten sein. Verwende ein modernes, sauberes Design."Dieser Ansatz ist ideal, um schnell die technische Machbarkeit zu prüfen, mit Interaktionen zu experimentieren oder funktionale Prototypen für Stakeholder zu erstellen, die "echten" Code sehen wollen.
Beispielprompt mit Claude + Ergebnis:
Erstelle eine moderne ansprechende Webseite mit HTML/CSS und JavaScript als One Pager, für eine Produkt-Detailseite. Sie soll oben ein großes Bild haben, rechts daneben den Produkttitel, eine kurze Beschreibung und einen 'In den Warenkorb'-Button. Darunter sollen drei kleine Bilder für weitere Ansichten sein. Verwende ein modernes, sauberes Design.

⚠️ Achtung: Ein Prototyp ist meist ein "Wegwerfprodukt". Sein einziger Zweck ist das Lernen. Er muss nicht perfekt sein und enthält keine echte Logik. Es geht darum, Annahmen schnell und günstig zu überprüfen.
Die vorangegangenen Kapitel haben die einzelnen Bausteine vorgestellt, aus denen sich ein robustes Systemkonzept zusammensetzt. Fassen wir diese Bausteine zu einem Gesamtprozess zusammen, spricht man von der benutzerorientierten Konzeptentwicklung.
Dieser Prozess ist die systematische Reise von einer vagen Idee hin zu einem konkreten, validierten und umsetzbaren Plan. Er stellt sicher, dass nicht am Nutzer vorbei entwickelt wird, sondern dessen Bedürfnisse und Erfahrungen im Zentrum aller Entscheidungen stehen.
Die Kernphasen dieses Prozesses sind:
Verstehen & Definieren (Requirement Engineering):
Visualisieren & Gestalten (User Experience Design):
Testen & Verfeinern (Prototyping & Iteration):
Dieser gesamte Zyklus ist das Herzstück der modernen Systemkonzeption.
Die Art und Weise, wie dieser Konzeptentwicklungsprozess durchlaufen wird, unterscheidet sich stark zwischen traditionellen und agilen Ansätzen.
| Merkmal | Traditionelles Modell (z.B. Wasserfall) | Agiles Modell (z.B. Scrum) |
|---|---|---|
| Zeitpunkt | In einer frühen, abgeschlossenen Designphase nach der Anforderungserhebung. | Kontinuierlich und iterativ in jedem Sprint. |
| Umfang | Es wird versucht, das gesamte System im Voraus zu konzipieren und zu gestalten. | Das Konzept wird inkrementell für die jeweils im Sprint umzusetzenden User Stories entwickelt. |
| Artefakte | Detaillierte, oft seitenlange UI-Spezifikationen und finale Mockups, die Teil des Pflichtenhefts werden. | Schlanke Artefakte wie Whiteboard-Skizzen, einfache Wireframes oder ein schnell erstellter Prototyp, der im Sprint-Review gezeigt wird. |
| Feedback | Hauptsächlich am Ende der Designphase durch den Auftraggeber. | Ständiges Feedback durch das Entwicklungsteam, den Product Owner und die Stakeholder am Ende jedes Sprints. |
| Flexibilität | Änderungen am Konzept sind nach der Designphase schwierig und teuer, da sie den gesamten Plan gefährden. | Änderungen sind erwünscht und einfach umzusetzen, da immer nur ein kleiner Teil des Systems betrachtet wird. |
💡 Merksatz: Während im Wasserfallmodell das Benutzerkonzept ein einmalig erstellter, starrer Bauplan ist, gleicht es im agilen Vorgehen eher einer Skizze, die in jedem Bauabschnitt (Sprint) basierend auf neuen Erkenntnissen verfeinert und angepasst wird.
Die besten Methoden sind nur so gut wie ihre Umsetzung. Um Anforderungen effizient zu verwalten, benötigen wir die richtigen Werkzeuge und eine klare Strategie, wie wir sie dokumentieren.
Stellen Sie sich vor, Sie hätten hunderte von Notizzetteln mit Anforderungen, aber kein System, um sie zu ordnen. Das Chaos wäre vorprogrammiert. Tools und Strategien sind unser Ordnungssystem.
Es gibt eine breite Palette von Werkzeugen, von sehr einfachen bis hin zu hochkomplexen.
Einfache Office-Anwendungen (Word, Excel):
Wiki-Systeme (z.B. Confluence):
Spezialisierte Projektmanagement-Tools (z.B. Jira, Trello, Asana):
Dedizierte Requirement-Management-Tools (z.B. IBM DOORS, Enterprise Architect):
Unabhängig vom Tool sind folgende Strategien entscheidend, um den Überblick zu behalten und die Qualität der Anforderungen sicherzustellen.
💡 Analogie: Stellen Sie sich vor, für ein Bauprojekt gäbe es mehrere, leicht unterschiedliche Baupläne, die an verschiedenen Orten lagern. Das Ergebnis wäre Chaos. Die "Single Source of Truth" ist der eine, gültige Master-Bauplan, auf den sich alle verlassen.
Was ist das? Eine "Single Source of Truth" (SSoT) ist das Prinzip, dass alle Informationen an einem einzigen, zentralen und autoritativen Ort gespeichert und gepflegt werden. Für das Anforderungsmanagement bedeutet das: Alle Anforderungen, von der ersten Idee bis zur finalen Spezifikation, leben an einem Ort. Es darf niemals Unklarheit darüber geben, welche Anforderungsliste die gültige ist.
Wozu dient das?
Wie wird das umgesetzt?
💡 Analogie: Denken Sie an die "Speichern unter..."-Funktion mit Datum im Dateinamen, aber professionell. Versionskontrollsysteme wie
Gitautomatisieren diesen Prozess. Jede Änderung ist eine neue, nachvollziehbare Version (ein "Commit") mit einer klaren Beschreibung, warum sie gemacht wurde.
Was ist das? Anforderungen leben – sie ändern sich. Ein Kunde präzisiert einen Wunsch, eine technische Randbedingung ändert sich, oder eine rechtliche Vorgabe kommt hinzu. Das Versionsmanagement macht diese Änderungen kontrolliert, transparent und nachvollziehbar.
Wozu dient das?
Wie wird das umgesetzt?
💡 Analogie: Stellen Sie sich ein Spinnennetz vor. Wenn Sie an einem Faden ziehen (eine Anforderung ändern), sehen Sie sofort, welche anderen Fäden (Code, Tests, Dokumente) sich mitbewegen. Ohne Traceability würden Sie im Dunkeln stochern und hoffen, alle betroffenen Stellen zu finden.
Was ist das? Traceability ist die Fähigkeit, eine Anforderung über ihren gesamten Lebenszyklus hinweg zu verfolgen und ihre Beziehungen zu anderen Artefakten (wie z.B. anderen Anforderungen, Testfällen, Code-Modulen oder Dokumentationskapiteln) darzustellen.
Wozu dient das? Traceability ist der Schlüssel zur Kontrolle über komplexe Systeme. Sie beantwortet kritische Fragen:
Wie wird das umgesetzt?
(REQ-001, TC-002) bedeutet: "Testfall TC-002 testet die Anforderung REQ-001".⚠️ Achtung: Ein Werkzeug ist nur ein Hilfsmittel, es ersetzt nicht das Denken und die Kommunikation. Ein "Fool with a tool is still a fool". Ein einfaches, aber konsequent genutztes System ist immer besser als ein komplexes Tool, das niemand versteht oder pflegt.
In diesem Kapitel vertiefen wir die Grundlagen des Projektmanagements und konzentrieren uns auf agile Methoden, die in der modernen Softwareentwicklung vorherrschend sind. Wir lernen, wie man Projekte flexibel plant und steuert, um schnell auf Änderungen reagieren zu können.
Nachdem wir die grundlegenden Unterschiede zwischen traditionellen und agilen Ansätzen verstanden haben, tauchen wir nun tiefer in die Welt der agilen Methoden ein. Agilität ist mehr als nur ein Prozess – es ist eine Denkweise, die auf den Werten und Prinzipien des Agilen Manifests basiert. In der Praxis prägen vor allem Scrum (Rahmenwerk für Zusammenarbeit und Planung) und Kanban (flussorientierte Arbeitssteuerung) die Organisation der Arbeit. Ergänzend liefert Extreme Programming (XP) keine Projektstruktur, sondern konkrete Engineering-Praktiken (z.B. TDD, Pair-Programming, Refactoring), die die technische Qualität in agilen Teams absichern – häufig direkt im Scrum-Kontext angewandt.
Stellen Sie sich eine professionelle Restaurantküche während des Hochbetriebs vor. Es gibt kein starres, monatelanges Vorausplanen jedes einzelnen Gerichts. Stattdessen arbeitet das Team in kurzen, intensiven Zyklen, reagiert auf eingehende Bestellungen, kommuniziert ständig und liefert kontinuierlich fertige Gerichte aus. Scrum liefert den Rhythmus und die Rollen, Kanban optimiert den Fluss an den Arbeitsstationen – und XP entspricht den Kochtechniken und Qualitätsstandards (Mise en Place, Verkostung, konstante Temperatur), die sicherstellen, dass jedes Gericht verlässlich in hoher Qualität entsteht.
Scrum ist das mit Abstand beliebteste agile Framework. Es ist kein detaillierter Prozess, sondern ein Rahmenwerk (Framework), innerhalb dessen Teams komplexe, adaptive Probleme lösen und dabei Produkte mit dem höchstmöglichen Wert kreativ und produktiv liefern können.
Stellen Sie sich ein Rugby-Team vor (woher der Name "Scrum" stammt). Das Team bewegt sich als geschlossene Einheit über das Spielfeld, passt sich ständig der Spielsituation an und hat ein klares Ziel vor Augen: den Ball über die Linie zu bringen.
Scrum basiert auf drei Säulen, die den empirischen Prozess steuern:
Scrum besteht aus drei Rollen, fünf Events (Ereignissen) und drei Artefakten.
Die Scrum-Rollen (Das Scrum Team):
Product Owner (Der Visionär):
Development Team (Die Umsetzer):
Scrum Master (Der Coach):
Die Scrum-Events (Der Rhythmus):
Alle Events in Scrum sind zeitlich begrenzt ("Time-boxed").
Der Sprint:
Sprint Planning:
Daily Scrum (Stand-up):
Sprint Review:
Sprint Retrospective:
Die Scrum-Artefakte (Die Werkzeuge):
Product Backlog:
Sprint Backlog:
Inkrement:
💡 Merksatz: Scrum ist einfach zu verstehen, aber schwer zu meistern. Es bietet einen klaren Rhythmus (Events) und klare Rollen, um in einem komplexen Umfeld durch kontinuierliches Feedback (Inspection & Adaptation) den bestmöglichen Wert zu schaffen.
Kanban (japanisch für "visuelle Karte" oder "Signal") ist keine Projektmanagement-Methode im gleichen Sinne wie Scrum, sondern ein Ansatz zur Verbesserung von Arbeitsabläufen. Es stammt ursprünglich aus der Produktionssteuerung von Toyota und wurde für die Softwareentwicklung und andere Wissensarbeitsbereiche adaptiert.
Stellen Sie sich eine Autobahn mit mehreren Spuren vor. Der Verkehr soll möglichst gleichmäßig und ohne Stau fließen. Kanban hilft dabei, den "Verkehr" der Aufgaben so zu steuern, dass Engpässe vermieden werden und die Arbeit kontinuierlich und effizient erledigt wird.
Visualisiere den Workflow:
Limitiere die angefangene Arbeit (Work in Progress - WIP):
Manage den Fluss (Flow):
Mache Prozessregeln explizit:
Implementiere Feedback-Schleifen:
Verbessere kollaborativ, evolviere experimentell:
Obwohl beide agil sind, haben sie unterschiedliche Schwerpunkte.
| Merkmal | Scrum | Kanban |
|---|---|---|
| Rhythmus | Zeitlich fixierte Sprints (z.B. 2 Wochen) | Kontinuierlicher Fluss (keine Sprints) |
| Fokus | Ein festes Ziel pro Sprint erreichen | Den Workflow optimieren und die Durchlaufzeit reduzieren |
| Rollen | Vordefiniert (Product Owner, Scrum Master, Dev Team) | Keine vordefinierten Rollen (man startet mit den bestehenden) |
| Änderungen | Änderungen innerhalb eines Sprints werden vermieden, um das Sprint-Ziel nicht zu gefährden | Änderungen sind jederzeit möglich, solange die WIP-Limits eingehalten werden |
| Metriken | Velocity (wie viele Story Points pro Sprint) | Cycle Time (Durchlaufzeit), Throughput (Durchsatz) |
| Ideal für... | Produktentwicklung mit klaren Release-Zyklen | Service-orientierte Teams (z.B. Support, Wartung) oder Teams, die einen bestehenden Prozess schrittweise verbessern wollen |
🔍 Vertiefung: Viele Teams nutzen eine Kombination aus beiden Ansätzen, oft als "Scrumban" bezeichnet. Sie arbeiten in Sprints (wie Scrum), nutzen aber ein Kanban-Board mit WIP-Limits, um den Workflow innerhalb des Sprints zu visualisieren und zu optimieren. Dies verbindet die Struktur von Scrum mit der Flexibilität und dem Fokus auf den Flow von Kanban.
Zweck: XP liefert konkrete Engineering-Praktiken, die agile Entwicklung technisch absichern: häufige, kleine Änderungen mit hoher Qualität und geringer Risiko-Kosten.
Kernpraktiken (Auswahl):
Wie passt XP zu Scrum/Kanban?
Wann besonders sinnvoll?
💡 Verweis: Praktische Integration von XP in Scrum siehe Abschnitt 4.2.3 „Scrum + XP“.
In der Praxis treffen wir selten auf die reine Lehre einer einzigen Projektmanagement-Methode. Stattdessen passen Organisationen und Teams ihre Vorgehensweisen an ihre spezifischen Bedürfnisse an. Hier kommen hybride Modelle ins Spiel. Sie sind pragmatische Lösungen, die gezielt Elemente aus verschiedenen Welten kombinieren, um die jeweiligen Vorteile zu nutzen.
Dabei lassen sich zwei typische Ausprägungen hybrider Ansätze unterscheiden:
💡In Projekten werden diese Ansätze oft mit Branchen spezifischen Engineering Praktiken kombiniert. Im Fall von Software - Projekten ist dies oft
Extreme Programming(kurzXP) - Teams ergänzen den organisatorischen Rahmen von Scrum bzw. Scrumban um die technischen Praktiken aus Extreme Programming (XP) wie z.B. TDD, Pair-/Mob-Programming, kontinuierliches Refactoring und CI/CD –, um Qualität, Änderbarkeit und Fluss zu erhöhen.
In den folgenden Abschnitten betrachten wir diese drei populären hybriden Modelle genauer: Water-Scrum-Fall, Scrumban und die Ergänzung von Scrum mit XP Programming.
Das Modell gliedert sich typischerweise in drei übergeordnete Phasen:
Phase 1: Wasserfall (Planung & Design)
Phase 2: Scrum (Entwicklung & Implementierung)
Phase 3: Wasserfall (Integration, Release & Wartung)
Dieser Ansatz eignet sich besonders in folgenden Situationen:
⚠️ Achtung: Die größte Herausforderung bei hybriden (statisch-agilen) Modellen ist der Übergang zwischen den Phasen. Es besteht die Gefahr, dass die agilen Prinzipien (wie Flexibilität und Reaktion auf Veränderung) durch den starren Rahmen des Wasserfalls ausgehöhlt werden. Eine klare Kommunikation und ein gutes Verständnis für beide Welten sind entscheidend für den Erfolg.
Stellen Sie sich vor, Sie haben die strukturierte Wochenplanung von Scrum (den Sprint), möchten aber die Flexibilität haben, auf dringende, unvorhergesehene Aufgaben zu reagieren, ohne den gesamten Plan über den Haufen zu werfen. Hier kommt Scrumban ins Spiel – ein hybrides Modell, das die Stärken von Scrum und Kanban vereint.
Scrumban ist kein offiziell definiertes Framework, sondern eine pragmatische Anpassung, die Teams vornehmen, um ihren Prozess zu optimieren. Es kombiniert die Zeremonien und Rollen von Scrum mit dem Fokus auf den Arbeitsfluss und die Visualisierung von Kanban.
Scrumban ist oft eine gute Wahl für:
🔍 Vertiefung: In Scrumban wird die Planung oft flexibler. Statt eines festen Sprint-Commitments plant das Team im Sprint Planning, welche Aufgaben es als Nächstes aus dem Backlog "ziehen" wird. Die Priorisierung kann während des Sprints angepasst werden, was eine schnellere Reaktion auf Änderungen ermöglicht als in reinem Scrum.
Viele Teams kombinieren Scrum mit Extreme Programming (XP), um die organisatorische Struktur von Scrum mit starken Engineering-Praktiken zu verbinden. Scrum beantwortet „wann“ und „mit wem“ (Rollen, Events, Artefakte) – XP beantwortet „wie“ wir qualitativ hochwertige, änderbare Software liefern.
💡 Merksatz: Scrum liefert den Rahmen, XP füllt ihn mit Technikdisziplin. Beginne mit DoD-Anpassung, Pairing-Plan, TDD und stabiler CI – der Rest wächst durch konsequentes Refactoring.
Quellen:
Nachdem wir die agilen Frameworks Scrum und Kanban kennengelernt haben, widmen wir uns nun dem Herzstück der agilen Umsetzung: der Planung von Iterationen, in Scrum Sprints genannt. Die Sprint-Planung ist das Ereignis, das den Rhythmus für die gesamte Entwicklungsarbeit vorgibt. Hier verpflichtet sich das Team auf ein erreichbares Ziel für den kommenden Zyklus.
Stellen Sie sich vor, Sie bereiten sich auf eine Bergtour vor, die aus mehreren Etappen besteht. Die Sprint-Planung ist die Besprechung am Morgen vor jeder Etappe. Das Team schaut auf die Gesamtkarte (das Product Backlog), entscheidet, welches Zwischenziel (das Sprint-Ziel) heute erreicht werden soll, und plant die genaue Route und die notwendigen Aufgaben, um dieses Ziel zu erreichen.
Das Sprint Planning ist ein zeitlich begrenztes Meeting (typischerweise maximal 8 Stunden für einen einmonatigen Sprint), das zu Beginn jedes Sprints stattfindet und zwei zentrale Fragen beantwortet:
Um eine fundierte Auswahl für den Sprint treffen zu können, muss das Team den Aufwand der Product-Backlog-Einträge schätzen. In agilen Teams wird Aufwand selten in Stunden oder Tagen geschätzt, sondern in abstrakten Einheiten, den Story Points.
Story Points: Sie sind eine relative Maßeinheit und bewerten den Gesamtaufwand einer User Story. Dieser Aufwand umfasst:
Planning Poker: Eine spielerische und kollaborative Technik zur Schätzung.
💡 Merksatz: Planning Poker fördert die Diskussion und stellt sicher, dass das Wissen aller Teammitglieder in die Schätzung einfließt. Es geht nicht darum, eine "perfekte" Zahl zu finden, sondern ein gemeinsames Verständnis für die Aufgabe zu entwickeln.
Die Planung eines Sprints findet nicht im luftleeren Raum statt. Eine der wichtigsten Randbedingungen ist die bereits existierende oder geplante System- und Software-Architektur.
Stellen Sie sich vor, Sie planen den Innenausbau eines Raumes. Ihre Planung hängt maßgeblich davon ab, ob die tragenden Wände, die Elektrik und die Wasseranschlüsse (die Architektur) bereits vorhanden und wie sie beschaffen sind.
⚠️ Achtung: In der agilen Welt wird Architektur oft als "emergent" (entstehend) betrachtet. Man entwirft nicht die gesamte Architektur für Jahre im Voraus, sondern beginnt mit einer minimalen, aber soliden Basis ("Walking Skeleton") und lässt sie mit jeder Iteration wachsen. Dennoch müssen grundlegende Architekturentscheidungen früh getroffen werden, da sie weitreichende Folgen haben. Wie man solche Architekturen entwirft und welche Muster es gibt, wird detailliert im nachfolgenden Kapitel 5 "Systementwurf und Architektur" behandelt.
Wenn Teams Scrum mit Kanban und XP kombinieren, verändert sich die Sprint-Planung an einigen Stellen spürbar – ohne den Scrum-Rahmen zu verlassen.
Stellen Sie sich vor, Sie sind der Architekt eines Wolkenkratzers. Bevor der erste Bagger anrollt, benötigen Sie einen detaillierten Bauplan. Dieser Plan legt nicht nur die Anordnung der Räume fest, sondern auch das Fundament, die tragenden Strukturen, die Elektrik und die Wasserversorgung. Ohne diesen Plan würde das Gebäude wahrscheinlich einstürzen oder zumindest unbrauchbar sein.
In der Softwareentwicklung ist die Softwarearchitektur dieser Bauplan. Sie definiert die grundlegende Struktur eines Systems, die Komponenten, aus denen es besteht, deren Beziehungen zueinander und die Prinzipien, die ihr Design und ihre Entwicklung leiten. Eine gute Architektur ist die Grundlage für ein robustes, wartbares und skalierbares System.
Die Wahl der Projektmanagementmethode hat einen erheblichen Einfluss darauf, wie die Softwarearchitektur entsteht und sich entwickelt. Die grundlegende Frage ist: Wird die Architektur im Voraus bis ins Detail geplant oder darf sie sich im Laufe des Projekts entwickeln?
Beim Wasserfallmodell wird versucht, die gesamte Architektur im Voraus zu entwerfen. Man erstellt einen umfassenden, detaillierten Bauplan, bevor die erste Zeile Code geschrieben wird.
In agilen Projekten wie mit Scrum entwickelt sich die Architektur iterativ mit dem Produkt. Man startet nicht mit einem perfekten, vollständigen Plan, sondern mit einer grundlegenden, aber funktionierenden Struktur.
Ein zentrales Konzept hierbei ist der "Walking Skeleton" (gehendes Skelett). Dies ist eine minimale, aber lauffähige End-to-End-Implementierung des Systems, die beweist, dass alle Architekturschichten (z.B. Frontend, Backend, Datenbank) korrekt miteinander verbunden sind. In den folgenden Sprints wird diesem Skelett dann "Fleisch auf die Knochen" gegeben, indem nach und nach Funktionalität hinzugefügt wird.
Dieser evolutionäre Ansatz ermöglicht es dem Team, frühzeitig technisches Feedback zu erhalten und die Architektur bei Bedarf anzupassen, ohne ein riesiges, im Voraus geplantes Design über den Haufen werfen zu müssen.
Architekturmuster sind bewährte Lösungsansätze für wiederkehrende Entwurfsprobleme. Ihre Eignung und Anwendung hängen stark von der gewählten Projektmethode ab.
🔍 Vertiefung: Clean, Onion & Modular Architecture Diese Muster (Clean/Onion als Varianten der Hexagonal Architecture und die Modular Architecture) teilen ein gemeinsames Ziel: starke Entkopplung und hohe Kohäsion. Sie sind prädestiniert für agile Vorgehensweisen, weil sie es erlauben, das System in unabhängige, testbare und separat entwickelbare Teile zu zerlegen. Die Kernlogik wird vor Änderungen in der volatilen Außenwelt (Technologie, Infrastruktur) geschützt, was eine nachhaltige und evolutionäre Entwicklung erst ermöglicht. In einem traditionellen Modell wäre der Versuch, all diese Module und ihre Schnittstellen perfekt im Voraus zu definieren, eine enorme und oft vergebliche Anstrengung.
Die Wahl der Architektur ist keine rein technische Entscheidung. Sie ist eng mit den Zielen des Projekts und der Arbeitsweise des Teams verknüpft. Agile Methoden begünstigen evolutionäre Architekturen, die mit den Anforderungen wachsen können (z.B. Microservices, Hexagonal Architecture). Traditionelle Methoden erfordern oft Architekturen, die im Voraus planbar sind (z.B. eine klassische Schichtenarchitektur). Das Wissen um diese Wechselwirkungen hilft Ihnen, eine bewusste und fundierte Entscheidung für Ihr Projekt zu treffen.
Nachdem wir die wichtigsten Architekturmuster im Überblick kennengelernt haben, wollen wir uns nun einige der einflussreichsten Muster im Detail ansehen. Wir beginnen mit der Clean Architecture, da sie viele der Prinzipien verkörpert, die für eine moderne, agile und wartbare Softwareentwicklung entscheidend sind.
Die Clean Architecture, populär gemacht durch Robert C. Martin ("Uncle Bob"), ist kein konkretes Framework, sondern ein Bauplan für eine testbare, UI-unabhängige, datenbankunabhängige und wartbare Systemarchitektur. Ihr oberstes Ziel ist die Trennung der Belange (Separation of Concerns) durch eine strikte Schichtung.
Das zentrale visuelle Modell sind konzentrische Kreise, die die verschiedenen Software-Schichten repräsentieren. Die wichtigste Regel lautet: Die Abhängigkeitsregel (The Dependency Rule).
💡 Die Abhängigkeitsregel: Quellcode-Abhängigkeiten dürfen immer nur von außen nach innen zeigen. Nichts in einer inneren Schicht darf etwas über eine äußere Schicht wissen. Insbesondere darf der Name einer äußeren Schicht nicht in einer inneren Schicht erwähnt werden.
Quelle: blog.cleancoder.com
Entities (Entitäten):
User, Order, Product). Sie enthalten die unternehmensweiten, kritischen Geschäftsregeln.Order-Klasse mit Methoden wie calculateTotalPrice() oder validateOrder().Use Cases (Anwendungsfälle):
CreateUserUseCase, PlaceOrderUseCase).Interface Adapters (Schnittstellen-Adapter):
Frameworks & Drivers (Frameworks & Treiber):
Eine typische Ordnerstruktur für ein Java-Projekt, das Clean Architecture verwendet und mit einem Build-Tool wie Maven oder Gradle verwaltet wird, könnte wie folgt aussehen. Jede Schicht wird oft als separates Modul oder Package innerhalb der src/main/java Struktur abgebildet.
mein-projekt/
├── pom.xml # Maven Build-Konfiguration
└── src/
└── main/
├── java/
│ └── com/
│ └── mein-unternehmen/
│ └── mein-projekt/
│ ├── domain/ # Domain Layer (Entities + Use Cases)
│ │ ├── entities/
│ │ │ └── User.java
│ │ └── usecases/
│ │ ├── CreateUserUseCase.java
│ │ └── GetUserUseCase.java
│ │ └── ports/
│ │ └── UserRepositoryPort.java // Interface
│ │
│ ├── application/ # Application Layer (optional, oft in infra)
│ │ └── services/
│ │ └── UserService.java // Implementiert Use Cases
│ │
│ ├── infrastructure/ # Infrastructure Layer
│ │ ├── adapters/
│ │ │ ├── web/
│ │ │ │ └── UserController.java # REST-Controller
│ │ │ └── persistence/
│ │ │ └── UserRepositoryImpl.java # Datenbank-Implementierung
│ │ └── config/
│ │ └── DependencyInjectionConfig.java
│ │
│ └── MainApplication.java # Frameworks & Drivers Layer
│
└── resources/
└── application.properties # Konfigurationsdateien
Erläuterung der Struktur:
domain: Der unabhängige Kern.
entities: Die reinen Geschäftsobjekte (User). Keine externen Abhängigkeiten.usecases: Die anwendungsspezifischen Geschäftsregeln (CreateUserUseCase).ports: Die Schnittstellen (UserRepositoryPort), die von der Infrastrukturschicht implementiert werden müssen.application: Diese Schicht dient als Vermittler zwischen den Layern. In kleineren Projekten werden ihre Aufgaben oft direkt von den Adaptern in der Infrastruktur übernommen.infrastructure: Konkrete Implementierungen für externe Abhängigkeiten.
adapters/web: Adapter, die die Anwendung von außen ansteuern (z.B. REST-Controller).adapters/persistence: Adapter, die von der Anwendung gesteuert werden (z.B. Datenbank-Repositories, die die ports implementieren).config: Konfiguration für Dependency Injection, Datenbankverbindungen etc.MainApplication.java: Der Einstiegspunkt der Anwendung (Frameworks & Drivers). Hier wird das Framework (z.B. Spring Boot) initialisiert, die Anwendung gestartet und die Abhängigkeiten werden "verdrahtet".💡 Diese Struktur erzwingt die Dependency Rule: Abhängigkeiten zeigen immer nach innen, von den konkreten Implementierungen (
infrastructure) hin zu den abstrakten Regeln (domain).
Nachdem wir uns im vorherigen Kapitel für eine grundlegende Software-Architektur (z.B. Clean Architecture) entschieden haben, beginnt der nächste entscheidende Schritt: der Systementwurf. Hier übersetzen wir den abstrakten Architektur-Blueprint in einen konkreten Bauplan für die Entwicklung. Ein zentraler Teil dieses Entwurfs ist die Schnittstellenspezifikation, auch bekannt als API-Design (Application Programming Interface).
Stellen Sie sich vor, die Software-Architektur ist die Entscheidung, ein Haus als "offenen Bungalow" zu bauen. Der Systementwurf legt nun fest, wo genau die Zimmer liegen, wie sie verbunden sind und wo sich Türen und Fenster (die Schnittstellen) befinden. Das API-Design beschreibt dann detailliert, wie diese Türen und Fenster aussehen, wie sie sich öffnen lassen und was man dahinter findet.
Dieses Kapitel dient als praktische Anleitung, wie Sie nach der Architekturwahl den Systementwurf in einem iterativen, agilen Prozess (z.B. in Sprints) gestalten und umsetzen können.
In einem agilen Umfeld entwerfen wir nicht die gesamte API für das ganze Projekt im Voraus. Das wäre ein Widerspruch zu den agilen Prinzipien. Stattdessen entwerfen und implementieren wir die API iterativ und inkrementell, Sprint für Sprint, basierend auf den User Stories, die den höchsten Wert für den Kunden liefern.
Der typische Ablauf pro Sprint sieht so aus:
POST /api/users/register).Dieser Zyklus wiederholt sich in jedem Sprint, sodass die API organisch mit dem Produkt wächst.
Ein bewährter Ansatz im modernen API-Design ist "API-First". Das bedeutet, die API wird entworfen und definiert, bevor die eigentliche Implementierung beginnt. Diese Definition dient als Vertrag zwischen verschiedenen Teilen des Systems (z.B. Frontend und Backend) oder sogar zwischen verschiedenen Teams.
Vorteile des API-First-Ansatzes:
Stellen wir uns vor, wir entwickeln eine neue Anwendung. Die erste User Story lautet: "Als neuer Benutzer möchte ich mich registrieren können, um die App nutzen zu können." Wir verfolgen die Entstehung der zugehörigen API über mehrere Sprints.
Ziel: Die Geschäftsregeln für die Benutzer-Registrierung implementieren und diese vollständig testbar machen, unabhängig von jeder externen Technologie.
Umsetzung:
Entity definieren: Eine einfache User-Klasse.
// application/domain/User.java
public class User {
private String name;
private String email;
// Konstruktoren, Getter, Setter...
}
Interne API (Port) definieren: Eine Schnittstelle (IUserRepository), die beschreibt, wie Benutzer gespeichert werden.
// application/ports/IUserRepository.java
public interface IUserRepository {
void save(User user);
User findByName(String name);
}
Use Case implementieren: Die CreateUser-Klasse enthält die reine Geschäftslogik
// application/usecases/CreateUser.java
public class CreateUser {
private final IUserRepository userRepository;
public CreateUser(IUserRepository userRepository) {
this.userRepository = userRepository;
}
public void execute(String name, String email) {
if (userRepository.findByName(name) != null) {
throw new IllegalStateException("Benutzername bereits vergeben.");
}
User newUser = new User(name, email);
userRepository.save(newUser);
}
}
💡 Warum fehlen hier Spring-Annotationen? Sie fragen sich vielleicht, warum
CreateUserkeine Annotation wie@Componenthat. Das ist Absicht und ein Kernprinzip der Clean Architecture! Der Use Case soll reine Geschäftslogik enthalten und komplett unabhängig von Frameworks wie Spring sein. Die Erstellung und Injektion der Abhängigkeiten wird extern in einer Konfigurationsklasse (AppConfig) gesteuert. So bleibt der Kern der Anwendung austauschbar und leicht testbar.
Testen mit einem Fake-Adapter: Ein InMemoryUserRepository für schnelle, zuverlässige Tests.
// infrastructure/persistence/InMemoryUserRepository.java
public class InMemoryUserRepository implements IUserRepository {
private final Map<String, User> users = new HashMap<>();
@Override
public void save(User user) {
users.put(user.getName(), user);
}
@Override
public User findByName(String name) {
return users.get(name);
}
}
Ergebnis des Sprints: Wir haben eine funktionierende, getestete Geschäftslogik. Die wichtigste Schnittstelle – die zwischen Logik und Datenhaltung – ist definiert und im Einsatz. Es gibt noch keine externe API.
Ziel: Die Funktionalität über eine grafische Desktop-Oberfläche bedienbar machen und dabei Spring für Dependency Injection nutzen.
Umsetzung:
View definieren (FXML): Die FXML-Datei bleibt unverändert. Sie deklariert die UI-Elemente und verweist auf die Controller-Klasse.
<!-- infrastructure/ui/fxml/register.fxml -->
<VBox xmlns:fx="http://javafx.com/fxml/1" fx:controller="infrastructure.ui.UserViewController">
<TextField fx:id="nameField" promptText="Benutzername"/>
<TextField fx:id="emailField" promptText="E-Mail"/>
<Button text="Registrieren" onAction="#handleRegister"/>
<Label fx:id="statusLabel"/>
</VBox>
UI-Adapter (Controller) als Spring-Bean: Der UserViewController wird zu einer von Spring verwalteten Komponente.
// infrastructure/ui/UserViewController.java
@Component // Markiert den Controller als Spring-Bean
public class UserViewController {
@FXML private TextField nameField;
@FXML private TextField emailField;
@FXML private Label statusLabel;
private final CreateUser createUser;
// Der Use Case wird hier per Konstruktor-Injection von Spring bereitgestellt
@Autowired
public UserViewController(CreateUser createUser) {
this.createUser = createUser;
}
@FXML
private void handleRegister() {
try {
createUser.execute(nameField.getText(), emailField.getText());
statusLabel.setText("Erfolgreich registriert!");
} catch (IllegalStateException e) {
statusLabel.setText(e.getMessage());
}
}
}
💡 Wer ruft den Konstruktor auf? Sie haben völlig recht, wenn Sie sich fragen, wer
new UserViewController(createUser)aufruft. Die Antwort ist der Kern von Spring: Sie rufen den Konstruktor nicht selbst auf – das Spring Framework übernimmt das für Sie!Dieser Prozess wird Inversion of Control (IoC) genannt:
- Beim Start der Anwendung scannt Spring Ihr Projekt nach Klassen, die mit Annotationen wie
@Componentmarkiert sind.- Es findet unseren
UserViewControllerund sieht: "Aha, diese Klasse hat einen Konstruktor, der eineCreateUser-Bean benötigt."- Spring schaut in seinem "Container" nach, ob es bereits eine
CreateUser-Bean hat (die wir inAppConfigdefiniert haben).- Sobald es die
CreateUser-Bean gefunden hat, ruft Spring internnew UserViewController(gefundeneCreateUserBean)auf und erstellt so eine vollständig initialisierte Instanz Ihres Controllers.Ihre einzige Aufgabe ist es, die Abhängigkeiten im Konstruktor zu deklarieren. Spring kümmert sich um die Bereitstellung dieser Abhängigkeiten. Sie geben die Kontrolle über die Objekterstellung an das Framework ab.
🔍 Vertiefung: Spring & JavaFX Integration Damit JavaFX Controller nutzen kann, die von Spring erstellt und verwaltet werden, ist ein kleiner "Trick" nötig. Man muss dem
FXMLLoadervon JavaFX mitteilen, dass er Spring nach einer passenden Bean fragen soll, anstatt die Controller-Klasse selbst zu instanziieren. Dies geschieht typischerweise über einenCallback:fxmlLoader.setControllerFactory(springContext::getBean);So wird die Brücke zwischen der JavaFX-Welt und dem Spring-Kontext geschlagen.
Ergebnis des Sprints: Die Funktionalität ist nun über eine Desktop-Anwendung nutzbar, die Dependency Injection von Spring verwendet. Die Kernlogik aus Sprint 1 musste dafür nicht verändert werden.
Ziel: Dieselbe Funktionalität zusätzlich über eine REST-API für Web-Frontends bereitstellen.
Umsetzung:
Spring Boot Konfiguration: Die Komponenten werden als Spring Beans verwaltet und automatisch injiziert.
// infrastructure/config/AppConfig.java
@Configuration
public class AppConfig {
@Bean
public IUserRepository userRepository() {
return new InMemoryUserRepository();
}
@Bean
public CreateUser createUser(IUserRepository userRepository) {
return new CreateUser(userRepository);
}
}
Web-Adapter (Controller) implementieren: Ein UserWebController nutzt Spring Boot und Spring RestController.
// infrastructure/web/UserWebController.java
@RestController
@RequestMapping("/api/users")
public class UserWebController {
private final CreateUser createUser;
@Autowired
public UserWebController(CreateUser createUser) {
this.createUser = createUser;
}
@PostMapping
public ResponseEntity<String> registerUser(@RequestBody UserRegistrationRequest request) {
try {
createUser.execute(request.getName(), request.getEmail());
return ResponseEntity.status(HttpStatus.CREATED).body("Erfolgreich registriert!");
} catch (IllegalStateException e) {
return ResponseEntity.status(HttpStatus.CONFLICT).body(e.getMessage());
}
}
}
// Ein einfaches DTO (Data Transfer Object) für die Anfrage
class UserRegistrationRequest {
private String name;
private String email;
// Getter und Setter
public String getName() { return name; }
public void setName(String name) { this.name = name; }
public String getEmail() { return email; }
public void setEmail(String email) { this.email = email; }
}
Dokumentation der API (Der Vertrag)
Der entworfene Endpunkt wird nun formal dokumentiert. Dies kann mit Werkzeugen wie Swagger/OpenAPI geschehen. Diese Spezifikation ist der "Vertrag" für alle Entwickler.
Beispiel (OpenAPI 3.0 in YAML):
openapi: 3.0.0
info:
title: Benutzer Registrierungs API
version: 1.0.0
paths:
/api/users:
post:
summary: Registriert einen neuen Benutzer
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/UserRegistrationRequest'
responses:
'201':
description: Benutzer erfolgreich registriert
content:
text/plain:
schema:
type: string
example: "Erfolgreich registriert!"
'409':
description: Benutzername bereits vergeben
content:
text/plain:
schema:
type: string
example: "Benutzername bereits vergeben."
components:
schemas:
UserRegistrationRequest:
type: object
required:
- name
- email
properties:
name:
type: string
example: "maxmustermann"
email:
type: string
format: email
example: "max.mustermann@example.com"
Ergebnis des Sprints: Die Funktionalität ist nun über zwei völlig unterschiedliche Frontends erreichbar (Desktop und Web). Die Kernlogik aus Sprint 1 blieb dabei die ganze Zeit über unberührt, was die Stärke der Clean Architecture demonstriert.
Nachdem wir nun unsere UserWebController in Sprint 3 implementiert haben, können wir sie als Fallstudie nutzen, um die fundamentalen Prinzipien eines guten REST-API-Designs zu verstehen. Eine gut gestaltete API ist vorhersehbar, leicht verständlich und einfach für andere Entwickler zu nutzen. Hier sind die Schlüsselprinzipien, die wir in unserem Beispiel angewendet haben:
Eine REST-API dreht sich um Ressourcen – also "Dinge" oder Entitäten – und nicht um Aktionen. Die URL (oder der Endpunkt) sollte die Ressource identifizieren, nicht das, was man damit tut.
@RequestMapping("/api/users") gewählt.
/api/users ist ein Substantiv (Nomen), das die Sammlung aller Benutzer-Ressourcen beschreibt./api/createUser wäre ein Verstoß gegen dieses Prinzip, da er eine Aktion (ein Verb) beschreibt.Die eigentliche Aktion wird nicht durch die URL, sondern durch die HTTP-Methode bestimmt.
HTTP stellt uns die Standard-Verben zur Verfügung, um mit den Ressourcen zu interagieren.
@PostMapping verwendet.
POST /api/users: Dies signalisiert eindeutig die Absicht, eine neue Entität innerhalb der /users-Sammlung zu erstellen.GET /api/users/{id}: Eine spezifische Benutzerressource abrufen (Read).PUT /api/users/{id}: Eine bestehende Benutzerressource vollständig aktualisieren (Update).DELETE /api/users/{id}: Eine Benutzerressource löschen (Delete).Statuscodes sind die universelle Sprache, mit der eine API dem Client das Ergebnis einer Anfrage mitteilt. Sie sind entscheidend für eine robuste Fehlerbehandlung auf der Client-Seite.
registerUser-Methode gibt klares und spezifisches Feedback.
ResponseEntity.status(HttpStatus.CREATED).body(...): Bei Erfolg senden wir den Status 201 Created. Das ist präziser als ein allgemeines 200 OK, denn es sagt dem Client explizit: "Ich habe die von dir gesendete Ressource erfolgreich erstellt."ResponseEntity.status(HttpStatus.CONFLICT).body(...): Wenn der Benutzername bereits existiert, senden wir 409 Conflict. Dies informiert den Client exakt über den Grund des Fehlschlags. Er kann dem Endbenutzer nun eine spezifische Meldung anzeigen ("Benutzername bereits vergeben") anstatt eines vagen "Fehler".Die Daten, die zwischen Client und API ausgetauscht werden, sollten auf das Nötigste beschränkt und klar strukturiert sein.
UserRegistrationRequest als DTO erstellt. Dies hat zwei entscheidende Vorteile:
User-Klasse). Wir geben nur die Felder preis, die für die Registrierung wirklich benötigt werden (name, email), und nicht potenziell sensible oder interne Daten.User-Klasse kann sich ändern (z.B. durch Hinzufügen eines passwordHash-Feldes), ohne dass die öffentliche API davon betroffen ist, solange das DTO stabil bleibt.Indem wir eine saubere interne Architektur (Clean Architecture) mit diesen etablierten API-Design-Prinzipien für unsere nach außen gerichteten Adapter kombinieren, bauen wir Systeme, die robust, wartbar und leicht in andere Anwendungen zu integrieren sind.
Nachdem wir uns mit der Anforderungserhebung, der Projektplanung und dem Entwurf der Software-Architektur beschäftigt haben, widmen wir uns nun einem entscheidenden Schritt, der die Qualität des Endprodukts sicherstellt: dem Testen. Ohne systematisches Testen ist die Entwicklung komplexer Software wie eine Seereise ohne Kompass – man hofft, am richtigen Ziel anzukommen, aber die Wahrscheinlichkeit, auf ein Riff zu laufen, ist hoch.
Stellen Sie sich vor, ein Autohersteller entwickelt ein neues Modell. Bevor das Auto auf den Markt kommt, werden unzählige Tests durchgeführt: Der Motor wird auf einem Prüfstand getestet (Unit-Test), das Zusammenspiel von Motor, Getriebe und Bremsen wird geprüft (Integrationstest), und schließlich wird das gesamte Auto auf einer Teststrecke unter realen Bedingungen gefahren und sogar gegen eine Wand gesetzt (System- & Sicherheitstests). Genau diese systematische Qualitätssicherung betreiben wir auch in der Softwareentwicklung.
Die Hauptziele des Testens sind:
💡 Merksatz: Testen ist nicht nur eine Phase am Ende des Projekts, sondern eine kontinuierliche Aktivität, die den gesamten Entwicklungsprozess begleitet, um Qualität von Anfang an einzubauen.
Es gibt verschiedene Arten von Tests, die auf unterschiedlichen Ebenen der Software ansetzen. Ein bewährtes Modell zur Visualisierung dieser Ebenen ist die Testpyramide. Sie zeigt, in welchem Verhältnis verschiedene Testarten stehen sollten, um eine effiziente und effektive Teststrategie zu gewährleisten.
|
|
Die Pyramide besteht aus drei Hauptebenen (von unten nach oben):
|
Die Logik dahinter: Tests an der Basis der Pyramide (Unit-Tests) sind klein, schnell, isoliert und kostengünstig zu schreiben und auszuführen. Je höher man in der Pyramide steigt, desto langsamer, komplexer und teurer werden die Tests. Daher sollte man viele schnelle Unit-Tests und nur wenige, gezielte E2E-Tests haben.
Ein Unit-Test überprüft die kleinste testbare Einheit (die "Unit" oder Komponente) der Software isoliert vom Rest des Systems. Diese Einheit ist oft eine einzelne Funktion, Methode oder Klasse.
Integrationstests prüfen das Zusammenspiel von zwei oder mehr Komponenten, die bereits einzeln durch Unit-Tests geprüft wurden.
Systemtests, oft auch als End-to-End (E2E)-Tests bezeichnet, prüfen das gesamte, voll integrierte System aus der Perspektive des Endanwenders.
In diesem Kapitel führen wir alle bisher gelernten Methoden und Techniken in einem größeren, zusammenhängenden Semesterprojekt zusammen. Ziel ist es, den gesamten Prozess von der Anforderung bis zum validierten Prototypen praxisnah zu durchlaufen.
Hier fassen wir die wichtigsten Erkenntnisse des Jahres zusammen und geben einen Ausblick auf weiterführende Themen und mögliche Spezialisierungen im Bereich Projektmanagement und Systemdesign.
In diesem Abschnitt werden alle wichtigen Fachbegriffe, die im Skript verwendet wurden, alphabetisch geordnet und kurz erklärt.
Agile Manifest: Ein 2001 veröffentlichtes Dokument, das die zentralen Werte und Prinzipien der agilen Softwareentwicklung formuliert. Es bevorzugt Individuen und Interaktionen, funktionierende Software, Zusammenarbeit mit dem Kunden und das Reagieren auf Veränderungen.
API (Application Programming Interface): Eine klar definierte Schnittstelle, die es verschiedenen Software-Komponenten ermöglicht, miteinander zu kommunizieren, ohne die internen Details der jeweils anderen Komponente kennen zu müssen.
API-First: Ein Design-Ansatz, bei dem die API entworfen und als Vertrag spezifiziert wird, bevor die eigentliche Implementierung beginnt. Dies ermöglicht paralleles Arbeiten von Teams (z.B. Frontend und Backend).
Akzeptanzkriterien: Konkrete, überprüfbare Bedingungen, die definieren, wann eine User Story oder ein Use Case als „fertig“ gilt; dienen als Grundlage für Tests und Abnahme.
Akzeptanztest: Test auf Geschäfts- bzw. Anwender-Ebene, der nachweist, dass eine Anforderung wie erwartet erfüllt ist; oft aus Akzeptanzkriterien abgeleitet.
Acceptance Test-Driven Development (ATDD): Vorgehen, bei dem Akzeptanztests gemeinsam vor der Implementierung definiert werden und als lebende Spezifikation dienen.
Akteur: Eine Person, eine Organisation oder ein externes System, das mit dem zu entwickelnden System interagiert, um ein Ziel zu erreichen. Akteure sind die Auslöser und Empfänger von Systemaktivitäten in einem Use Case.
Anforderung (Requirement): Eine Bedingung oder Fähigkeit, die ein System erfüllen muss. Man unterscheidet funktionale (was es tut) und nicht-funktionale (wie es etwas tut) Anforderungen.
Big Design Upfront (BDUF): Ein traditioneller Ansatz (oft im Wasserfallmodell), bei dem versucht wird, die gesamte Systemarchitektur und das Design detailliert im Voraus zu planen, bevor die Implementierung beginnt.
Beobachtung (Feldbeobachtung): Eine Erhebungstechnik, bei der ein Anforderungsanalyst einen Benutzer direkt in seiner natürlichen Arbeitsumgebung beobachtet, um tatsächliche Arbeitsabläufe, Herausforderungen und unausgesprochene Bedürfnisse zu verstehen.
Baseline: Ein eingefrorener, freigegebener Referenzstand eines Anforderungs- oder Dokumenten-Sets, gegen den spätere Änderungen verglichen werden.
Backlog Refinement: Laufende Pflege und Detaillierung des Product Backlogs (Zerlegen, Klären, Schätzen, Priorisieren) zur Sprint-Vorbereitung.
Barrierefreiheit (Accessibility): Gestaltung digitaler Produkte so, dass sie auch von Menschen mit Einschränkungen ohne Hürden genutzt werden können (z.B. Kontraste, Tastaturbedienbarkeit, Screenreader-Texte).
Clean Architecture: Ein von Robert C. Martin populär gemachtes Architekturmuster, das die Trennung der Belange durch konzentrische Schichten betont. Die zentrale "Dependency Rule" besagt, dass Abhängigkeiten nur nach innen gerichtet sein dürfen, um die Geschäftslogik (Kern) von externen Details (UI, DB) zu isolieren.
Critical Path Method (CPM): Eine Projektmanagement-Technik zur Identifizierung der längsten Abfolge von abhängigen Aufgaben, die die Gesamtdauer des Projekts bestimmt. Der "kritische Pfad" hat keinen Zeitpuffer.
Consumer-Driven Contracts (CDC): Vertragstests, bei denen die Erwartungen der API-Verbraucher die vertragliche Schnittstelle definieren; stellen Kompatibilität zwischen Consumer und Provider sicher.
Contract Testing (Vertragstests): Tests, die die Einhaltung einer vereinbarten Schnittstellenspezifikation zwischen unabhängigen Komponenten/Services verifizieren.
Continuous Integration (CI): Praxis, Code-Änderungen häufig in den Main-Branch zu integrieren und automatisch zu bauen/testen, um Integrationsprobleme früh zu erkennen.
Cycle Time: Durchlaufzeit einer Arbeitseinheit vom Start bis zum Abschluss; zentrale Fluss-Metrik insbesondere in Kanban.
Dependency Rule (Abhängigkeitsregel): Die Kernregel der Clean Architecture. Sie besagt, dass Quellcode-Abhängigkeiten nur von einer äußeren Schicht auf eine innere Schicht zeigen dürfen.
DTO (Data Transfer Object): Ein Objekt, das Daten zwischen Prozessen oder Schichten transportiert. DTOs werden oft verwendet, um Daten von der Datenbank- oder Domänenschicht zur Präsentationsschicht zu übertragen, ohne die Geschäftslogik preiszugeben.
Daily Scrum: Tägliches, kurzes Synchronisationsmeeting des Entwicklungsteams (max. 15 Minuten) zur Planung der nächsten 24 Stunden und Sichtbarmachung von Hindernissen.
Definition of Done (DoD): Teaminterne, verbindliche Qualitäts-Checkliste, die festlegt, wann Arbeit wirklich „fertig“ ist (inkl. Tests, Review, Integration, Doku …).
Development Team (Entwicklungsteam): Die Umsetzer im Scrum Team; interdisziplinär, selbstorganisiert, verantwortlich für das Inkrement am Sprint-Ende.
Entity (Entität): Im Kontext der Clean Architecture ein Kern-Geschäftsobjekt der Anwendung, das unternehmensweite, kritische Geschäftsregeln enthält und von allen äußeren Schichten unabhängig ist.
Event-Driven Architecture: Ein Architekturmuster, bei dem Komponenten asynchron über das Senden und Empfangen von Ereignissen (Events) kommunizieren, anstatt sich direkt aufzurufen. Dies fördert eine lose Kopplung.
Empirische Prozesskontrolle (Empiricism): Grundprinzip von Scrum: Entscheidungen basieren auf Beobachtung/Erfahrung mittels Transparenz, Überprüfung (Inspection) und Anpassung (Adaptation).
Enabler Story: Arbeitseinheit, die technische Grundlagen schafft (z.B. Architektur/Tooling), um künftige Features zu ermöglichen, ohne direkten Nutzerwert zu liefern.
Extreme Programming (XP): Sammlung technischer Praktiken (u.a. TDD, Pair Programming, Refactoring, CI) zur Qualitätssicherung in agiler Entwicklung.
Fragebogen (Umfrage): Eine Erhebungstechnik, bei der eine standardisierte Liste von Fragen an eine große Anzahl von Personen verteilt wird, um quantitative Daten und Meinungen zu sammeln.
Funktionale Anforderung: Beschreibt eine spezifische Funktion oder ein Verhalten, das das System bereitstellen muss (z.B. "Der Benutzer kann sich einloggen").
Feature Flag: Schalter im Code, um Funktionen zur Laufzeit gezielt zu aktivieren/deaktivieren; ermöglicht kleine, risikominimierte Releases.
Gantt-Diagramm: Ein Balkendiagramm zur Visualisierung eines Projektzeitplans. Es zeigt die Start- und Enddaten von Projektaufgaben und deren Abhängigkeiten.
Hexagonal Architecture (Ports & Adapter): Ein Architekturmuster, das die Kernlogik einer Anwendung von externen Einflüssen (wie UI, Datenbank) durch klar definierte Schnittstellen (Ports) und deren Implementierungen (Adapter) entkoppelt.
Hybrides Modell: Ein Projektmanagement-Ansatz, der Elemente aus traditionellen (z.B. Wasserfall) und agilen (z.B. Scrum) Methoden kombiniert, um von den Vorteilen beider Welten zu profitieren.
Interview: Eine Erhebungstechnik, bei der ein Anforderungsanalyst ein direktes Gespräch mit einem Stakeholder führt, um detaillierte Informationen, Meinungen und Anforderungen zu ermitteln.
INVEST: Ein Akronym, das die Qualitätskriterien für gute User Stories beschreibt: Independent (Unabhängig), Negotiable (Verhandelbar), Valuable (Wertvoll), Estimable (Schätzbar), Small (Klein) und Testable (Testbar).
Impediment: Ein Hindernis, das das Scrum Team an der Zielerreichung hindert; dessen Beseitigung ist Aufgabe des Scrum Masters.
Inkrement: Die Summe der im Sprint fertiggestellten Backlog-Einträge; nutzbarer Produktstand, der der DoD entspricht.
Iteration: Zeitlich begrenzter, wiederkehrender Entwicklungszyklus zur inkrementellen Lieferung von Wert (z.B. ein Sprint in Scrum).
Kanban: Ein agiles Framework, das sich auf die Visualisierung des Arbeitsflusses (oft auf einem Kanban-Board), die Begrenzung der laufenden Arbeit (Work in Progress) und die kontinuierliche Verbesserung konzentriert.
Kanban-Board: Sichtbare Darstellung des Workflows mit Spalten (z.B. To Do, In Arbeit, Done), auf dem Arbeitselemente als Karten fließen.
Kano-Modell: Methode zur Klassifikation von Produktmerkmalen nach ihrem Einfluss auf Kundenzufriedenheit (Basis-, Leistungs-, Begeisterungsmerkmale etc.).
Lastenheft: Ein Dokument, in dem der Auftraggeber seine gesamten Anforderungen und Wünsche an ein zu entwickelndes System aus seiner Sicht beschreibt ("Was" soll das System leisten?).
Layered Architecture (Schichtenarchitektur): Ein klassisches Architekturmuster, das ein System in horizontale Schichten wie Präsentation, Geschäftslogik und Datenzugriff unterteilt.
Lead Time: Zeitspanne von der Anforderung bis zur Auslieferung an den Kunden; wichtig für Fluss- und Liefertempo-Bewertung.
Microkernel Architecture (Plugin-Architektur): Ein Architekturmuster, das aus einem schlanken Kernsystem und erweiterbaren Funktionalitäten besteht, die als "Plugins" angebunden werden.
Microservices: Ein Architekturstil, bei dem eine komplexe Anwendung in eine Sammlung kleiner, unabhängiger und autonomer Services zerlegt wird, die über ein Netzwerk kommunizieren.
Mock: Eine simulierte Version eines Objekts oder einer Schnittstelle (z.B. einer API), die in Tests oder während der Entwicklung verwendet wird, um Abhängigkeiten zu ersetzen und paralleles Arbeiten zu ermöglichen.
Minimum Viable Product (MVP): Minimale Produktversion mit ausreichend Nutzen, um Feedback echter Nutzer zu erhalten und Hypothesen zu validieren.
MoSCoW-Methode: Einfache Priorisierungstechnik mit Klassen Must/Should/Could/Won’t have zur Release-Planung.
Mockup: Detaillierter, statischer Design-Entwurf einer Oberfläche (Look & Feel), jedoch ohne Interaktivität.
Nicht-funktionale Anforderung: Beschreibt Qualitätsmerkmale oder Randbedingungen des Systems, wie z.B. Leistung, Sicherheit, Benutzerfreundlichkeit oder Zuverlässigkeit (z.B. "Die Antwortzeit muss unter 1 Sekunde liegen").
OpenAPI: Eine weit verbreitete Spezifikation zur Beschreibung von REST-APIs. Sie definiert Endpunkte, Datenmodelle und Operationen in einem standardisierten, maschinenlesbaren Format (oft YAML oder JSON).
PERT (Program Evaluation and Review Technique): Eine Projektmanagement-Methode zur Schätzung der Projektdauer unter Berücksichtigung von Unsicherheiten, indem optimistische, pessimistische und wahrscheinlichste Schätzungen für Aufgabendauern verwendet werden.
Pflichtenheft: Ein Dokument, in dem der Auftragnehmer (Entwickler) beschreibt, wie er die Anforderungen aus dem Lastenheft technisch umsetzen wird ("Wie" werden die Anforderungen realisiert?).
Projekt: Ein einmaliges, zeitlich begrenztes Vorhaben mit einem klaren Ziel, definierten Ressourcen und einem festgelegten Anfangs- und Endpunkt.
Projektmanagement: Die Anwendung von Wissen, Fähigkeiten, Werkzeugen und Techniken auf Projektaktivitäten, um die Projektanforderungen zu erfüllen. Es umfasst die Planung, Steuerung, Überwachung und den Abschluss von Projekten.
Pair Programming: Zwei Entwickler arbeiten gemeinsam am selben Code (Treiber/Navigator), um Qualität und Wissenstransfer zu erhöhen.
Persona: Fiktiver, evidenzbasierter Nutzer-Prototyp, der Zielgruppenbedürfnisse, Ziele und Verhaltensweisen greifbar macht.
Planning Poker: Kollaborative Schätzmethode mit verdeckten Karten (oft Fibonacci), um Konsens über Story-Point-Schätzungen zu erreichen.
Product Backlog: Geordnete, dynamische Liste aller bekannten Anforderungen an das Produkt; Eigentum des Product Owners.
Product Owner: Rolle im Scrum Team; verantwortet Produktvision, Wertmaximierung und Priorisierung des Product Backlogs.
Prototyp: Interaktives, klickbares Modell eines Produkts zur schnellen Validierung von Annahmen vor der Implementierung.
Pull-Prinzip: Arbeit wird erst begonnen, wenn Kapazität im nächsten Prozessschritt frei ist; zentral für Flusssteuerung (Kanban).
Requirement-Engineering: Der systematische Prozess der Ermittlung, Dokumentation, Validierung und Verwaltung von Anforderungen für ein System. Es ist der Oberbegriff für das Requirement-Management.
Requirement-Management: Ein Teilbereich des Requirement-Engineerings, der sich auf die Verwaltung, Priorisierung und Nachverfolgung von Anforderungen über den gesamten Projektlebenszyklus konzentriert.
REST (Representational State Transfer): Ein Architekturstil für verteilte Systeme, insbesondere für Web-APIs. REST-APIs nutzen Standard-HTTP-Methoden (GET, POST, PUT, DELETE) und sind ressourcenorientiert.
Refactoring: Strukturverbesserung von bestehendem Code ohne Verhaltensänderung zur Erhöhung von Verständlichkeit und Änderbarkeit.
Scrum: Ein agiles Framework für die iterative und inkrementelle Entwicklung von Produkten. Die Arbeit wird in kurzen Zyklen, sogenannten "Sprints", organisiert.
Scrumban: Ein hybrides Modell, das die strukturierten Zeremonien und Rollen von Scrum mit dem auf den Arbeitsfluss fokussierten Ansatz von Kanban kombiniert.
Service-Oriented Architecture (SOA): Ein Architekturmuster, bei dem Geschäftsanwendungen aus einer Sammlung wiederverwendbarer, lose gekoppelter Dienste (Services) aufgebaut werden, die über ein Netzwerk kommunizieren.
Softwarearchitektur: Der grundlegende "Bauplan" eines Softwaresystems. Sie definiert die Struktur, die Komponenten, deren Beziehungen zueinander und die Prinzipien, die ihr Design und ihre Entwicklung leiten.
Stakeholder: Jede Person, Gruppe oder Organisation, die ein Interesse an einem Projekt hat, es beeinflussen kann oder von dessen Ergebnis betroffen ist (z.B. Kunden, Nutzer, Entwickler, Management).
Standardablauf (Happy Path): Die Beschreibung des idealen, fehlerfreien Schritt-für-Schritt-Ablaufs in einem Use Case, bei dem alles wie erwartet funktioniert.
Systementwurf: Der Prozess, bei dem der abstrakte Architektur-Blueprint in einen konkreten Bauplan für die Entwicklung übersetzt wird. Er umfasst Entscheidungen über Module, Komponenten und deren Schnittstellen.
Scrum Master: Servant-Leader des Scrum Teams; fördert das Verständnis von Scrum, beseitigt Impediments und schützt das Team.
Single Source of Truth (SSoT): Prinzip, alle maßgeblichen Informationen an einem autoritativen Ort zu pflegen, um Inkonsistenzen zu vermeiden.
Spike: Zeitlich begrenzte Forschungs- oder Experimentieraufgabe zur Risikoreduktion bzw. Entscheidungsfindung.
Sprint: Zeitlich fixierter Entwicklungszyklus (max. 1 Monat, meist 2 Wochen) zur Lieferung eines „Done“-Inkrements.
Sprint Backlog: Vom Team ausgewählte Backlog-Einträge plus Umsetzungsplan für einen Sprint.
Sprint Planning: Scrum-Event zu Sprint-Ziel, Auswahl und Umsetzungsplan der Arbeit für den kommenden Sprint.
Sprint Review: Scrum-Event zur Vorführung des Inkrements mit Stakeholder-Feedback und Backlog-Anpassung.
Sprint Retrospektive: Scrum-Event zur kontinuierlichen Verbesserung des gemeinsamen Arbeitsprozesses.
Story Points: Relative Maßeinheit zur Aufwandsschätzung von Backlog-Einträgen (Komplexität, Arbeit, Unsicherheit).
Traceability (Nachverfolgbarkeit): Die Fähigkeit, eine Anforderung über ihren gesamten Lebenszyklus hinweg zu verfolgen – von ihrer Entstehung über das Design und die Implementierung bis hin zum Test.
Throughput: Anzahl abgeschlossener Arbeitseinheiten pro Zeitintervall; Metrik zur Beurteilung der Lieferrate.
Trunk-Based Development: Entwicklungsstrategie mit sehr kurzen Branches und häufigen Integrationen in den Hauptzweig zur Minimierung von Merge-Konflikten.
Test-Driven Development (TDD): Entwicklungsansatz, bei dem Tests vor dem Produktionscode geschrieben werden (Red–Green–Refactor), um Design und Qualität zu steuern.
Use Case: Eine Beschreibungstechnik, die die Interaktion zwischen einem Akteur (Benutzer oder System) und dem zu entwickelnden System darstellt, um ein bestimmtes Ziel zu erreichen.
User Story: Eine kurze, einfache Beschreibung einer Funktion aus der Perspektive des Nutzers, typischerweise im Format: "Als <Rolle> möchte ich <Ziel>, um <Nutzen> zu erreichen."
UML (Unified Modeling Language): Standardisierte Modellierungssprache zur visuellen Darstellung von Software-Systemen (z.B. Use-Case-, Klassen-, Sequenzdiagramme).
Usability (Gebrauchstauglichkeit): Maß, in dem ein Produkt effektiv, effizient und zufriedenstellend von bestimmter Nutzergruppe in bestimmtem Kontext verwendet werden kann.
User Experience (UX): Gesamtheit der Eindrücke und Erlebnisse eines Nutzers bei der Interaktion mit einem System, inkl. Nützlichkeit, Benutzbarkeit und Freude.
User Interface (UI): Sichtbare und bedienbare Schnittstelle eines Systems zum Nutzer (z.B. Bedienelemente, Layout, Interaktionen).
Walking Skeleton: Eine minimale, aber lauffähige End-to-End-Implementierung eines Systems in einem agilen Projekt. Es dient als Beweis, dass alle Architekturschichten korrekt miteinander verbunden sind, und wird in späteren Iterationen mit Funktionalität ("Fleisch") angereichert.
Wasserfallmodell: Ein traditionelles, sequenzielles Projektmanagement-Modell, bei dem die Projektphasen (Analyse, Design, Implementierung, Test) nacheinander und ohne Überlappung durchlaufen werden.
Workshop: Eine moderierte Arbeitssitzung, bei der eine Gruppe von Stakeholdern zusammenkommt, um gemeinsam Anforderungen zu erarbeiten, zu diskutieren und abzustimmen.
Water-Scrum-Fall: Hybrides Vorgehensmodell mit plangetriebenen Phasen vor/nach einer agilen Scrum-Entwicklung.
Wireframe: Grobe, schematische Skizze einer Oberfläche mit Fokus auf Struktur und Funktion, noch ohne visuelles Feindesign.
YAGNI (You Aren’t Gonna Need It): Prinzip des einfachen Designs: nur das implementieren, was für die aktuelle Anforderung nötig ist, nicht auf Vorrat.
Velocity: Geschwindigkeit eines Scrum-Teams, gemessen als Anzahl erledigter Story Points pro Sprint; dient der Prognose, nicht der Zielvorgabe.
Der Anhang enthält ergänzende Materialien, wie z.B. Vorlagen, Checklisten oder weiterführende Links.